Version 1.4 of ai12s/ai12-0275-1.txt

Unformatted version of ai12s/ai12-0275-1.txt version 1.4
Other versions for file ai12s/ai12-0275-1.txt

!standard 8.5.1(2/3)          18-06-14 AI12-0275-1/02
!standard 8.5.1(3/2)
!class Amendment 18-05-10
!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
subtype_marks are 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.
!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.

****************************************************************



Questions? Ask the ACAA Technical Agent