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

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

--- ai12s/ai12-0396-1.txt	2020/09/04 03:49:56	1.1
+++ ai12s/ai12-0396-1.txt	2020/09/11 23:02:19	1.2
@@ -1,4 +1,4 @@
-!standard 3.2.4(1/3)                                 20-09-03  AI12-0396-1/01
+!standard 3.2.4(1/3)                                 20-09-10  AI12-0396-1/02
 !standard 6.1.1(1/5)
 !standard 7.3.2(1/4)
 !standard 7.3.3(1/5)
@@ -19,6 +19,8 @@
 !standard 13.14(7.2/3)
 !standard 13.14(15.1/3)
 !class binding interpretation 20-09-03
+!status Amendment 1-2012 20-09-10
+!status ARG Approved 11-0-3  20-09-09
 !status work item 20-09-03
 !status received 20-09-03
 !priority Medium
@@ -68,7 +70,7 @@
 explain better any "alterations" that occur as part of inheritance of a
 name or an expression? (Yes.)
 
-(4) Another area of confusion is the use of the term "specifies."  For
+(4) Another area of confusion is the use of the term "specifies".  For
 representation and operational items, we state in RM 13.1 that an aspect
 is "specified" for an entity if it is either "directly specified" by
 such an item referring to an entity, or if it is inherited from another
@@ -79,7 +81,7 @@
 related? (Yes.)
 
 (5) We currently have two kinds of aspects, namely "representation" and
-"operational."  There is some sense that having a third kind of aspect
+"operational". There is some sense that having a third kind of aspect
 might simplify the wording job, presuming the aspects of this third kind
 have more in common with each other than with other kinds of aspects,
 resulting in fewer special cases in the wording. One possibility is to
@@ -169,13 +171,6 @@
   type), the following language-defined {assertion} aspect may be
   specified with an aspect_specification (see 13.1.1):
 
-Modify 7.3.4(4/5):
-
-  For a nonformal private type, nonformal private extension, or full
-  type that does not have a partial view, the following language-defined
-  {assertion} aspects may be specified with an aspect_specification (see
-  13.1.1):
-
 Modify 9.5(53/5):
 
   [A]It is illegal to {directly} specify aspect Nonblocking for the
@@ -203,7 +198,7 @@
 
   A pragma Assertion_Policy applies to the named assertion aspects in a
   specific region, and applies to all assertion expressions {associated
-  with those aspects,} specified in that region.
+  with those aspects} specified in that region.
 
 Modify 13.1(8/3):
 
@@ -288,12 +283,12 @@
 
    * For an operational aspect that is a name:
 
-      * if the name denotes a primitive subprogram of the type, the
-        inherited aspect is a name that denotes the corresponding
-        primitive subprogram of the derived type;
+      * if the name denotes one or more primitive subprograms of the
+        type, the inherited aspect is a name that denotes the
+        corresponding primitive subprogram(s) of the derived type;
 
       * otherwise, the inherited aspect is a name that denotes the same
-        entity as the original aspect;
+        entity or entities as the original aspect;
 
    * For an operational aspect that is an expression or an aggregate,
      the inherited aspect is a corresponding expression or aggregate where
@@ -313,7 +308,7 @@
   for that aspect. {[Redundant:  For aspects that are neither
   type-related nor subtype-specific, the terms /specified/ and /directly
   specified/ are equivalent.]}
-  
+
 Modify 13.1(18.2/3)
 
   An aspect_specification or representation item that specifies a
@@ -327,6 +322,17 @@
   aspect to be the same as the definition it would have by default is
   said to be /confirming/; otherwise it is /nonconfirming/.}
 
+Add after 13.1.1(18.1/4):
+
+  If a given aspect is type-related and inherited, then within an
+  aspect_definition for the aspect, if a name resolves to denote
+  multiple visible subprograms, all or none of the denoted subprograms
+  shall be primitives of the associated type.
+
+     AARM Reason: This is necessary because the inheritance rules for
+     names denoting primitive subprograms are different from those for
+     names denoting other entities -- see 13.1.
+  
 Modify 13.1.1(18.3/5):
 
   If a nonoverridable aspect is directly specified for a type T, then
@@ -340,7 +346,7 @@
   expression for the inherited aspect, with the added rule that an
   identifier that is specific to the aspect is the same as the
   corresponding identifier in the inherited aspect.}
-   
+
 Modify AARM 13.1.1 (18.c/5):
 
   Reason: If more than one progenitor of a type T specifies a
@@ -349,7 +355,7 @@
   the aspect that depend on [the view of the type; that would violate the
   definition of type aspects being the same for all views of a type]
   {which progenitor we inherit from}.
-  
+
 Modify 13.13.2(37.1/5):
    The [aspect] Nonblocking {aspect} is [the Boolean literal]{statically} False 
    {and the Global aspect is null} for the default implementations of 
@@ -401,7 +407,7 @@
 !discussion
 
 We have chosen to define a notion of an "assertion aspect" but we chose
-not to say it is true "third" kind of aspect, but rather just a special
+not to say it is a true "third" kind of aspect, but rather just a special
 case of operational aspect, with some special rules. This results in
 less wording change, particularly in 13.1, but still gives us a chance
 to talk about the assertion aspects as a group, if certain rules do or

Questions? Ask the ACAA Technical Agent