!standard 8.5.1(2/3) 18-08-31 AI12-0275-1/03 !standard 8.5.1(3/2) !class Amendment 18-05-10 !status Amendment 1-2012 18-07-05 !status ARG Approved 7-0-0 18-06-24 !status work item 18-05-10 !status received 17-10-15 !priority Low !difficulty Easy !subject Make subtype_mark optional in object renames !summary The subtype_mark in object renaming declarations is made optional, and can be skipped when there is no ambiguity with regards to the type of the renamed expression. !problem The subtype_mark in an object renaming is often redundant, especially when used to introduce local renamings that are aimed at clarifying the intent of the code. Moreover, the constraints, exclusions, and predicates of the subtype_mark are ignored in favor of those of the renamed object, so the subtype_mark can't be trusted to provide accurate information about the object. !proposal Make the subtype_mark optional in object renaming declarations. The expression will be correctly typed as long as the right hand object_name can be resolved to only one specific type. !wording Replace 8.5.1(2/3) with: object_renaming_declaration ::= defining_identifier [: [null_exclusion] subtype_mark] renames object_name [aspect_specification]; | defining_identifier : access_definition renames object_name [aspect_specification]; Replace 8.5.1(3/2) with: The type of the object_name shall resolve to the type determined by the subtype_mark, if present. If no subtype_mark or access_definition is present, the expected type of the object_name is any type. In the case where the type is defined by an access_definition, the type of the object_name shall resolve to an anonymous access type. If the anonymous access type is an access-to-object type, the type of the object_name shall have the same designated type as that of the access_definition. If the anonymous access type is an access-to-subprogram type, the type of the object_name shall have a designated profile that is type conformant with that of the access_definition. !discussion One doesn't want to make the access_definition optional; it's a new type and we don't want to be declaring types implicitly. This will make renamings easier to read when the renamed object is a type conversion or qualified expression -- the type name is completely redundant in those cases. !corrigendum 8.5.1(2/3) @drepl @xcode<@fa@fa< ::= > @fa : [@fa] @fa @ft<@b @i>@fa [@fa]; | @fa : @fa @ft<@b @i>@fa [@fa];> @dby @xcode<@fa@fa< ::= > @fa [: [@fa] @fa] @ft<@b @i>@fa [@fa]; | @fa : @fa @ft<@b @i>@fa [@fa];> !corrigendum 8.5.1(3/2) @drepl The type of the @i@fa shall resolve to the type determined by the @fa, or in the case where the type is defined by an @fa, to an anonymous access type. If the anonymous access type is an access-to-object type, the type of the @i@fa shall have the same designated type as that of the @fa. If the anonymous access type is an access-to-subprogram type, the type of the @i@fa shall have a designated profile that is type conformant with that of the @fa. @dby The type of the @i@fa shall resolve to the type determined by the @fa, if present. If no @fa or @fa is present, the expected type of the @i@fa is any type. In the case where the type is defined by an @fa, the type of the @i@fa shall resolve to an anonymous access type. If the anonymous access type is an access-to-object type, the type of the @i@fa shall have the same designated type as that of the @fa. If the anonymous access type is an access-to-subprogram type, the type of the @i@fa shall have a designated profile that is type conformant with that of the @fa. !ASIS [Not sure. It might be necessary to remove/make optional access to the subtype name of a renaming. - Editor.] !ACATS test ACATS B- and C-Tests are needed to check that the new capability is supported. !appendix From: Raphaël Amiard Sent: Friday, June 15, 2018 3:21 AM Here is my homework for AI12-0275 [This is version /01 of the AI - Editor.] **************************************************************** From: Tucker Taft Sent: Friday, June 15, 2018 5:15 AM Looks good. We don't usually say "shall resolve to exactly one type" in the RM. Other places where we have similar constructs, we say "the expected type is any type" (e.g. 4.6 Conversions) or the construct "is a complete context" (e.g. 8.6(4-10, 28-31). Saying that something will resolve to exactly one type is redundant with the rule in 8.6(32) which disallows ambiguity. Probably saying something like the following would be more consistent with other parts of the RM: The type of the object_name shall resolve to the type determined by the subtype_mark, if present. If no subtype_mark or access_definition is present, the expected type of the object_name is any type. **************************************************************** From: Raphaël Amiard Sent: Friday, June 15, 2018 5:22 AM Sounds good! I was actually roaming the RM looking for the proper phrasing but couldn't find it :) Thanks! Updated version attached [This is version /02 of the AI - Editor.] **************************************************************** From: Randy Brukardt Sent: Friday, June 15, 2018 7:38 PM > Updated version attached For the record, a couple of editorial changes that I applied. (1) The !summary starts: subtype_mark in object renaming declarations is made optional... This reads as a fragment; it probably should start with "The": The subtype_mark in object renaming declarations is made optional... (2) In the !problem, I added a sentence noting that the subtype can't even be trusted: Moreover, the constraints, exclusions, and predicates of the subtype_mark are ignored in favor of those of the renamed object, so the subtype_mark can't be trusted to provide accurate information about the object. (3) In !proposal, "...as long as the right hand expression's can be non ambiguously resolved to only one specific type." There doesn't seem to be any property of the object_name (it's not an expression, look at the syntax :-) that requires the possessive form (or even the plural form), so the "'s" is unneeded. And "non ambiguously resolved" seems redundant: "resolved" by itself is good enough (there's no such thing as "ambiguously resolved" - that's an error!). Thus: "...as long as the right hand object_name can be resolved to only one specific type." I find "right hand" and "only" also to be unnecessary here, but that's less clear cut so I left them for now. (Gotta have something to discuss in Lisbon!) I also wonder if "specific" is a bad choice of words here: it seems to imply that a class-wide object cannot be renamed this way. Maybe it would be better to leave "only" and drop "specific". (4) In !wording, changed "Modify xxx as follows" to "Replace xxx with" (two places). When an AI uses "Modify" some wording, the given wording shows the changes using [] and {}. We use "Replace" if only the new wording is given. Syntax changes are always "replaced", because the use of [] and {} would be ambiguous. Note that if I don't do this nitpicking, some reviewer very well might, causing more work in the future. (5) I used the !discussion from the /0 version of the AI, with the "probably" removed. Technical aside: This appears to be the first way to get multiple views of an anonymous access object, with different names (defining identifier). In all previous cases, each view had a unique type. Not sure that matters, but it might somehow. Specifically: procedure Foo (P : access Integer) is R renames P; S : access Integer renames P; begin Here R has the same anonymous access type as P. The explicit case S has different (but matching) types. **************************************************************** From: Raphaël Amiard Sent: Friday, June 22, 2018 3:23 AM Thanks Randy for the update! See you this afternoon :) ****************************************************************