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

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

--- ai12s/ai12-0342-1.txt	2020/01/16 05:28:53	1.6
+++ ai12s/ai12-0342-1.txt	2020/01/17 03:50:44	1.7
@@ -1,9 +1,11 @@
 !standard 4.2.1(0)                                     20-01-15  AI12-0342-1/04
+!standard 3.9.2(1/2)
 !standard 6.3.1(22)
 !reference AI12-0249-1
 !reference AI12-0295-1
 !reference AI12-0325-1
 !class Amendment 19-09-10
+!status Amendment 1-2012 20-01-15
 !status ARG Approved 9-0-4  20-01-15
 !status work item 19-09-10
 !status received 19-08-15
@@ -42,8 +44,23 @@
-In 4.2.1(2/5), delete "nonoverridable, ".
+Modify the first sentence of 3.9.2(1/2):
+    The primitive subprograms of a tagged type, the subprograms declared 
+    by formal_abstract_subprogram_declarations,
+    {the subprograms identified by the user-defined literal aspects of a 
+    specific tagged type (see 4.2.1),} and the stream attributes of a 
+    specific tagged type that are available (see 13.13.2) at the end of 
+    the declaration list where the type is declared are called dispatching 
+    operations.
+Modify 4.2.1(2/5):
+    The following [nonoverridable, ]type-related operational 
+    aspects {(collectively known as *user-defined literal aspects*)} may be 
+    specified for any type T:
 In 4.2.1(3/5, 4/5, and 5/5), replace (once in each)
    "that denotes a primitive function of T" with "that statically denotes a 
@@ -61,7 +78,7 @@
    End AARM Ramification.
-   These three aspects are inherited according to the rules given in 13.1.
+   User-defined literal aspects are inherited according to the rules given in 13.1.
    AARM Discussion:
       This means that in this example
@@ -107,20 +124,41 @@
 Append after 4.2.1(6/5) (at the end of the Legality Rules section)
-   If a nonabstract tagged type other than a null extension inherits any of
-   these three aspects, then each inherited aspect shall be directly 
-   specified for the type.
+   If a nonabstract tagged type other than a null extension inherits any 
+   user-defined literal aspect, then each inherited aspect shall be 
+   directly specified for the type.
 Delete 4.2.1(7-8/5).
    [This is the entire Dynamic Semantics section (it is now redundant).]
+Modify 4.2.1(9/5):
-Replace 6.3.1(22-22.a)
+   It is a bounded error if the evaluation of a literal that has an expected 
+   type with a specified [Integer_Literal, Real_Literal, or 
+   String_Literal]{user-defined literal} aspect, propagates an exception. 
+   Either Program_Error or the exception propagated by the evaluation is 
+   raised at the point of use of the value of the literal. If it is recognized 
+   prior to run time that evaluation of such a literal will inevitably (if 
+   executed) result in such a bounded error, then this may be reported as an 
+   error prior to run time.
+Modify AARM 4.2.1(9.a/5):
+   As always, an implementation may apply "as-if" optimizations (those that 
+   result in the same external effects in the absence of erroneous execution) 
+   to the function calls associated with user-defined literals. In particular,
+   if the function associated with a [_Literal]{user-defined literal} aspect 
+   has a Global aspect that indicates no references to global variables, then 
+   a number of optimizations are available to the implementation: 
+Replace 6.3.1(22-22.a):
   - each primary that is a literal in one has the same value as the
     corresponding literal in the other. 
   AARM Ramification: The literals may be written differently.
    - each primary that is a literal in one is a user-defined literal
      if and only if the corresponding literal in the other is also a
      user-defined literal. Furthermore, if neither are user-defined literals
@@ -130,6 +168,21 @@
+We've changed the definition of these aspects to be similar to the 
+stream-oriented attributes. Thus, we've dropped the "nonoverridable" and
+"primitive subprogram" requirements, only requiring that the subprogram
+has the appropriate profile and is statically denoted.
+This change also requires us to define this to be a dispatching operation
+(so that T'Class has literals if T has literals), and that requires ensuring
+that there is an appropriate function defined (similar to the way 3.9.3
+requires functions of non-null extensions to be overridden).
+We define a name for these attributes collectively so that we can easily
+name them in various rules.
 Because these are aspects, we don't get reemergence with
 formal derived types (the way that we might with primitive
 subprograms). That means that in this example,
@@ -803,5 +856,25 @@
 of your emails, Randy.  I agree that your "meta rule" is a good start, and it 
 would be nice to discuss it explicitly in the ARG meeting, hopefully with 
 some examples (since in the abstract it can be pretty hard to decide!).
+Editor's Note (January 16th, 2020)
+The proposed wording had "each inherited aspect shall be overridden". But
+"shall be overridden" is not defined for aspects, we should have said
+"shall be directly specified".
+We want these aspects to be dispatching for tagged types, so that they are
+available for classwide subtypes. That requires specific wording in 3.9.2(1).
+To keep that wording from being unwieldy, we need to name these aspects. After
+consulting with Tucker Taft and Steve Baird, "user-defined literal aspects"
+was chosen. We then used this name rather than other vague descriptions or
+lists of attributes - this makes the wording of 4.2.1 much clearer (and more
+resistant to future problems should we decide to add Character_Literal or
+Null_Literal in the future).
+We considered this part of the editorial review of this AI.

Questions? Ask the ACAA Technical Agent