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 @@
 
 !wording
 
-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 
     function"
@@ -61,7 +78,7 @@
          end;
    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.
 
-with
+with:
    - 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 @@
 
 !discussion
 
+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