CVS difference for ai12s/ai12-0275-1.txt

Differences between 1.3 and version 1.4
Log of other versions for file ai12s/ai12-0275-1.txt

--- ai12s/ai12-0275-1.txt	2018/06/16 00:08:34	1.3
+++ ai12s/ai12-0275-1.txt	2018/06/16 00:57:06	1.4
@@ -1,4 +1,5 @@
-!standard 8.5.1(2/3)                                  18-06-14  AI12-0275-1/01
+!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
@@ -7,37 +8,40 @@
 !subject Make subtype_mark optional in object renames
 !summary
 
-subtype_mark in object renaming declarations is made optional, and can be
+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.
+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 expression's can be non
-ambiguously resolved to only one specific type.
+will be correctly typed as long as the right hand object_name can be resolved
+to only one specific type.
 
 !wording
 
-Modify 8.5.1(2/3) as follows:
+Replace 8.5.1(2/3) with:
 
-2/3     object_renaming_declaration ::=
+     object_renaming_declaration ::=
             defining_identifier [: [null_exclusion] subtype_mark]
          renames object_name
                 [aspect_specification];
           | defining_identifier : access_definition renames object_name
                 [aspect_specification];
 
-Modify 8.5.1(3/2) as follows:
+Replace 8.5.1(3/2) with:
 
-3/2 The type of the object_name shall resolve to the type determined by the
-subtype_mark, if present. If no subtype_mark is present, the type of the
-object_name shall resolve to exactly one type.
+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
@@ -48,7 +52,7 @@
 
 !discussion
 
-Probably one doesn't want to make the access_definition optional; it's
+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
@@ -65,23 +69,111 @@
 !appendix
 
 From: RaphaŽl Amiard
-Sent: Friday, June 15, 3:21 AM
+Sent: Friday, June 15, 2018  3:21 AM
 
 Here is my homework for AI12-0275 [This is version /01 of the AI - Editor.]
 
 ****************************************************************
 
-From: RaphaŽl Amiard
-Sent: Friday, June 15, 3:21 AM
+From: Tucker Taft
+Sent: Friday, June 15, 2018  5:15 AM
 
-Here is my homework for AI12-0275 [This is version /01 of the AI - Editor.]
+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, 3:21 AM
+Sent: Friday, June 15, 2018  5:22 AM
 
-Here is my homework for AI12-0275 [This is version /01 of the AI - Editor.]
+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