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

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0419-1.txt

--- ai12s/ai12-0419-1.txt	2021/01/15 05:51:42	1.1
+++ ai12s/ai12-0419-1.txt	2021/01/23 05:57:34	1.2
@@ -1,4 +1,4 @@
-!standard 3.2.4(1/5)                                  21-01-14  AI12-0419-1/01
+!standard 3.2.4(1/5)                                  21-01-21  AI12-0419-1/02
 !standard 3.2.4(29.5/4)
 !standard 3.9.2(1/5) 
 !standard 4.2.1(6/5)
@@ -16,6 +16,8 @@
 !standard 13.13.2(25.1/2)
 !standard 13.13.2(42/2)
 !class Amendment 21-01-14
+!status Amendment 1-2012 21-01-21
+!status ARG Approved 16-0-0  21-01-20
 !status work item 21-01-14
 !status received 21-01-14
 !priority Low
@@ -32,28 +34,28 @@
    1) implicitly composed
      Implicitly composed aspects are not inherited per se, but the
      aspect for a derived type is implicitly composed from that of its
-     parent type.  The aspects of an ancestor never "reemerge" in a
+     parent type. The aspects of an ancestor never "reemerge" in a
      generic; the actual type's "actual" aspect definition is invoked. 
      This makes sense because these aspects are generally defined for
      private types, and in that case there is no ancestor aspect to
-     reemerge.    
+     reemerge.  
 
    2) additive
      Additive aspects are not inherited, but they "apply" to their
-     descendants, using a "notional formal derived type" model.  In
+     descendants, using a "notional formal derived type" model. In
      a generic, the type's "actual" aspect definition is invoked
-     as appropriate, even if untagged.  As with the implicitly
+     as appropriate, even if untagged. As with the implicitly
      composed aspects, these are meaningful on private types,
      so reemergence of an ancestor's aspect would not make sense.
 
    3) nonoverridable
      Nonoverridable aspects are inherited, but cannot be overridden
      except with a "confirming" definition which matches that of the
-     parent type as defined in 13.1.  On the other hand, the named
+     parent type as defined in 13.1. On the other hand, the named
      subprograms can be overridden, and that is the way to alter the
      effect of a nonoverridable aspect in a derived type. For a formal
      untagged derived type, the ancestor's nonoverridable aspects, if
-     any reemerge, which is not surprising, because the primitive
+     any, reemerge, which is not surprising because the primitive
      subprograms of the untagged ancestor reemerge as well.
    
 Ancestor aspects of formal tagged types never reemerge thanks to the
@@ -68,10 +70,7 @@
 
 The Put_Image aspect is considered to be implicitly composed as well.
 
-We have two options in this AI relating to the user-defined literal
-aspects.  In OPTION 1, the user-defined literal aspects are
-nonoverridable.  In OPTION 2, these aspects don't quite fit into any of
-the above categories, but the closest is implicitly composed.  
+The user-defined literal aspects are nonoverridable.
 
 !question
 
@@ -90,9 +89,7 @@
 operational aspects?  (This AI attempts to clarify them.)
 
 What are the inheritance and re-emergence rules for the user-defined
-literal aspects? (OPTION 1: it is nonoverridable; OPTION 2: it is
-similar to "implicitly constructed" but requires re-specifying the
-aspect for a non-null type extension.)
+literal aspects? (They are nonoverridable.)
 
 !recommendation
 
@@ -108,7 +105,7 @@
   predicate specification is an aspect_specification for one of the two
   predicate aspects. General rules for aspects and aspect_specifications
   are found in Clause 13 (13.1 and 13.1.1 respectively). The predicate
-  aspects are assertion aspects (see 11.4.2).{  [Redundant: The
+  aspects are assertion aspects (see 11.4.2).{ [Redundant: The
   predicate aspects are not inherited, but their effects are additive,
   as defined below.]}
 
@@ -120,7 +117,7 @@
     any) of S (in an arbitrary order){, after a (view) conversion of the
     value to the corresponding parent or progenitor type};
     
-Modify 3.9.2(1/5): [OPTION 1]
+Modify 3.9.2(1/5):
 
   The primitive subprograms of a tagged type, the subprograms declared
   by formal_abstract_subprogram_declarations, the [subprograms
@@ -130,20 +127,10 @@
   at the end of the declaration list where the type is declared are
   called dispatching operations. [... rest as before]
 
-Modify 3.9.2(1/5): [OPTION 2]
+Modify 4.2.1(6/5):
 
-  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){, the Put_Image attribute of a specific tagged type}, 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. [... rest as before]
-    
-Modify 4.2.1(6/5): [OPTION 1]
-
   User-defined literal aspects are [inherited according to the rules
-  given in 13.1] nonoverridable (see 13.1).
+  given in 13.1] nonoverridable (see 13.1.1).
 
 Modify 4.10(4/5):
 
@@ -201,7 +188,7 @@
   expression. Type_Invariant'Class may be specified on a
   private_type_declaration, or a private_extension_declaration, or a
   full_type_declaration for an interface type. Type_Invariant'Class
-  determines a class-wide type invariant for a tagged type. {[Redudant:
+  determines a class-wide type invariant for a tagged type. {[Redundant:
   The Type_Invariant'Class aspect is not inherited, but its effects are
   additive, as defined below.]}
 
@@ -226,7 +213,7 @@
   
 Delete 13.1(15.9/5)  [NOTE: it is no longer relevant because
 implicitly-composed aspects are not inherited, even for untagged
-derived types.  Here is what it currently says:
+derived types. Here is what it currently says:
 
   When an aspect that is a subprogram is inherited, the derived type
   inherits the aspect in the same way that a derived type inherits a
@@ -238,10 +225,10 @@
   such aspects are inherited by derived types according to the rules
   given in 13.1. Any legality rule associated with a nonoverridable
   aspect is re-checked for the derived type, if the derived type is not
-  abstract.  Certain type-related and subtype-specific aspects are
+  abstract. Certain type-related and subtype-specific aspects are
   defined to be /additive/; such aspects are not inherited, but they can
   /apply/ to the types derived from, or the subtypes based on, the
-  original type or subtype, as defined for each such aspect.  Finally,
+  original type or subtype, as defined for each such aspect. Finally,
   certain type-related aspects are /implicitly composed/; such aspects
   are not inherited, but rather a default implementation for a derived
   type is provided, as defined for each such aspect, based on that of
@@ -259,7 +246,7 @@
   type, these attributes are not inherited, but rather the default
   implementations are used.] {
 
-  For type extensions{, in the default implementation}, the Write or
+  For type extensions, in the default implementation, the Write or
   Read attribute for the parent type is called, followed by the Write or
   Read attribute of each component of the extension part, in canonical
   order. For a limited type extension, if the attribute of the parent
@@ -323,26 +310,26 @@
 However, there are two significant changes:
 
   1) We have said that the Put_Image aspects are not inherited, but are
-  rather implicitly composed.  Before we were silent on what happened
+  rather implicitly composed. Before we were silent on what happened
   with an untagged derived type.
 
-  2) We suggest two options for handling user-defined literal aspects:
+  2) We treat user-defined literal aspects as nonoverridable. The current
+  wording suggests that they are a separate operation, but says that
+  they are inherited as defined in 13.1. This presumably was referring to
+  stream-attribute style inheritance, although nonoverridable inheritance
+  is also (partially) defined there.
+  
+We considered using a form of "implicitly composed" inheritance for 
+user-defined literals. This would have the advantage that an extension could
+have the literal operation and the originally associated operation do 
+different things (which could be necessary if the named operation is useful
+user operation in its own right, such as the From_String conversion originally
+defined for BigNums). But it would have the disadvantage that for a non-null
+type extension, the aspect is *required* to be re-specified, again, even if 
+it is to just use the overriding of the previously named primitive. That would
+necessary as such functions are required to be overridden, and a similar rule
+would be needed for such aspects.
 
-      a) OPTION 1: Treat them as nonoverridable, meaning that in a
-      derived type the parent aspect is inherited, and the named
-      subprogram can be overridden to change the details of
-      the conversion from string(s).
-
-      b) OPTION 2: Treat them as a separate operation, where they are
-      inherited as is, and need to be re-specified to do anything
-      different, even if it is to just use the overridding of the
-      previously named primitive.  For a non-null type extension, the
-      aspect is *required* to be re-specified, again, even if it is to
-      just use the overriding of the previously named primitive.
-
-The AI author recommends OPTION 1, but has retained OPTION 2 as it
-matches the current semantics.
-
 !examples
 
     type T is private
@@ -353,30 +340,27 @@
     
     overriding
     function From_String(S : String) return T2;
+
+The overriding From_String is used for converting integer literals for T2.
 
-In OPTION 1, the overriding From_String is used for converting integer
-literals for T2, but in OPTION 2, the overriding From_String is not
+In the rejected alternative, the overriding From_String would not be
 used, unless you repeat the "with Integer_Literal => From_String" on the
-declaration of T2.  In OPTION 2, you had the ability to have T2 use a
-different operation for converting literals.  In OPTION 1, you are
+declaration of T2. In this alternative, you would have had the ability to have
+T2 use a different operation for converting literals. As defined, you are
 limited to using "From_String" in all descendants, because the aspect is
 nonoverridable.
    
 !ASIS
 
-[Not sure. It seems like some new capabilities might be needed,
-but I didn't check - Editor.]
+No ASIS effect.
 
 !ACATS test
 
 ACATS B- and C-Tests are needed to check that Put_Image works properly
-for derived types. If Option 1 is chosen, then we also need ACATS B- and
-C-Tests are needed to check that the user-defined literal aspects are
-nonoverrideable. For option 2, we also need ACATS B- and
-C-Tests are needed to check that the original user-defined literal
-aspects is used for a derived type.
+for derived types. We also need ACATS B- and C-Tests are needed to 
+check that the user-defined literal aspects are nonoverrideable.
 
-No tests are needed for other aspects as no semantic change is needed. 
+No tests are needed for other aspects as no semantic change is intended. 
 
 !appendix
 

Questions? Ask the ACAA Technical Agent