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

Differences between 1.9 and version 1.10
Log of other versions for file ai12s/ai12-0342-1.txt

--- ai12s/ai12-0342-1.txt	2020/04/21 23:35:08	1.9
+++ ai12s/ai12-0342-1.txt	2020/12/09 06:25:04	1.10
@@ -1,4 +1,4 @@
-!standard 4.2.1(0)                                     20-04-17  AI12-0342-1/05
+!standard 4.2.1(0)                                     20-12-08  AI12-0342-1/06
 !standard 3.9.2(1/2)
 !standard 6.3.1(22)
 !reference AI12-0249-1
@@ -58,7 +58,7 @@
 
     The following [nonoverridable, ]type-related operational 
     aspects {(collectively known as *user-defined literal aspects*)} may be 
-    specified for any type T:
+    specified for a type T:
 
 
 In 4.2.1(3/5, 4/5, and 5/5), replace (once in each)
@@ -68,8 +68,9 @@
 Append after 4.2.1 (5/5) (at the end of the Static Semantics section)
 
    AARM Ramification:
-      The following example is legal because the preceding rules
-      are name resolution rules (see 13.1.1):
+      The following example is legal because the resolution 
+      of an aspect_definition for an aspect that is defined to be a subprogram
+      is based on the profile required for that aspect (see 13.1.1):
          package Pkg1 is
             type T is record X, Y : Integer; end record
               with Integer_Literal => Int_Lit;
@@ -1137,6 +1138,55 @@
 
 [9] I put quite a bit of the above into the !discussion of the AI.
 
+****************************************************************
+
+From the AARM review of Tucker Taft (October 2020)
+
+We introduce the aspects in paragraph (2/5) with:
+
+2/5: The following type-related operational aspects 
+(collectively known as user-defined literal aspects) may be 
+specified for any type T:
+
+It feels like the "for any type T" is somewhat misleading, in 
+that later we limit these aspects to non-numeric, or 
+non-string types.  Perhaps simply say "for a type T:" to 
+finesse the issue.
+
+[Editor's response:]
+Technically, of course, a Legality Rule that says you can't *specify* an 
+aspect for some type is not the same thing as saying that the aspect is 
+*defined* for a type. Of course, in this case where the default value of the 
+aspect is to not have a literal function, the difference is somewhat academic.
+
+However, "any type" is the wording used for attributes, not for aspects. 
+Aspects generally just say "for a <blah>". So your suggestion is less a 
+finesse and more just the way it ought to be done for consistency.
 
+> We have the following AARM note:
+> 
+> 5.b/5: Ramification: {AI12-0342-1} The following example is 
+> legal because the preceding rules are Name Resolution Rules 
+> (see 13.1.1):
+> 
+> But the rules are listed in the Static Semantics section, so 
+> this is confusing, even with the "see 13.1.1" which 
+> presumably clarifies (?).  Perhaps we could put this all 
+> under the Name Resolution section title. 
+
+That would be inconsistent with all of the other aspect definitions, and also 
+potentially would be wrong. I think the problem here is the note, as it's an 
+oversimplification. 13.1.1(8/3) says that for an aspect that denotes a 
+subprogram, the aspect definition is a name and the expected profile for the 
+name is the one defined for the aspect. So these rules define the kind of 
+aspect (subprogram) and the profiles defined for the aspect. That's Static 
+Semantics. And then the Name Resolution Rule in 13.1.1 uses those definitions 
+for resolution of the aspect_definition. So the note should say something like:
+
+  5.b/5: Ramification: The following example is legal because the resolution 
+  of an aspect_definition for an aspect that is defined to be a subprogram is
+  based on the profile required for that aspect (see 13.1.1):
 
+
 ****************************************************************
+

Questions? Ask the ACAA Technical Agent