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

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

--- ai12s/ai12-0396-1.txt	2020/09/11 23:02:19	1.2
+++ ai12s/ai12-0396-1.txt	2020/11/26 02:27:02	1.3
@@ -1,8 +1,7 @@
-!standard 3.2.4(1/3)                                 20-09-10  AI12-0396-1/02
+!standard 3.2.4(1/3)                                 20-11-24  AI12-0396-1/04
 !standard 6.1.1(1/5)
 !standard 7.3.2(1/4)
 !standard 7.3.3(1/5)
-!standard 7.3.4(4/5)
 !standard 9.5(53/5)
 !standard 11.4.2(9/3)
 !standard 11.4.2(10.2/3)
@@ -14,7 +13,8 @@
 !standard 13.1(15.1/3)
 !standard 13.1(18.1/3)
 !standard 13.1(18.2/3)
-!standard 13.1(18.3/5)
+!standard 13.1.1(18.1/4)
+!standard 13.1.1(18.3/5)
 !standard 13.13.2(37.1/5)
 !standard 13.14(7.2/3)
 !standard 13.14(15.1/3)
@@ -95,7 +95,7 @@
 (6) The default stream attributes need to have well defined aspects,
 right? (Yes.)
 
-!recommentation
+!recommendation
 
 (1) We have revised 13.1(11/3) and 13.1(9.1/5) to limit most of the
 restrictions to representation aspects, and to define distinct
@@ -213,7 +213,7 @@
   
 Add after AARM 13.1(8.aa):
 
-  * Object_Size clause,
+  * Object_Size clause
   
 Modify 13.1(9.1/5):
 
@@ -243,7 +243,11 @@
 
     {AARM Proof: The syntax of incomplete_type_declarations and
     formal_incomplete_type_declarations do not allow for an
-    aspect_specification.}
+    aspect_specification. The prefix of an attribute_reference
+    cannot name an incomplete type (see 3.10.1), so no 
+    attribute_definition_clause can be used with an incomplete type.
+    Similarly, the local_name of a representation pragma cannot name an
+    incomplete type, so no such pragmas can be used with an incomplete type.}
     
 Modify 13.1(13/3):
 
@@ -322,6 +326,12 @@
   aspect to be the same as the definition it would have by default is
   said to be /confirming/; otherwise it is /nonconfirming/.}
 
+Modify AARM 13.1 (29.p/3):
+   Correction: Specifying a language-defined aspect for a generic formal 
+   parameter is no longer allowed. {Note: This correction is repealed in
+   Ada 202x, as a number of aspects are allowed on formals in that
+   later language version.} ...
+
 Add after 13.1.1(18.1/4):
 
   If a given aspect is type-related and inherited, then within an
@@ -356,11 +366,14 @@
   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 
-   stream-oriented attributes {for elementary types. For the default 
-   implementations of  stream-oriented attributes for composite types, the 
+Replace 13.13.2(37.1/5):
+   The aspect Nonblocking is the Boolean literal False for the default 
+   implementations of stream-oriented attributes.
+with:
+   The Nonblocking aspect is statically True and the Global aspect is 
+   null for the default implementations of 
+   stream-oriented attributes for elementary types. For the default 
+   implementations of stream-oriented attributes for composite types, the 
    value of the Nonblocking aspect is that of the first subtype, and
    the Global aspect defaults to that of the first subtype. A 
    default implementation of a stream-oriented attribute that has the 
@@ -369,7 +382,7 @@
    implementations of the stream-oriented attributes Read, Read'Class,
    Input, and Input'Class; the aspect Dispatching is Write(Stream) for
    the default implementations of the stream-oriented attributes Write,
-   Write'Class, Output, and Output'Class}.
+   Write'Class, Output, and Output'Class.
  
    AARM Ramification: If the default implementation of a stream-oriented
    attribute A for a composite type would call other stream-oriented attribute(s) 
@@ -443,6 +456,252 @@
 aspects that are neither type related nor subtype specific, because
 there is no inheritance for such aspects.
 
+!corrigendum 3.2.4(1/3)
+
+@drepl
+The language-defined @i<predicate aspects> Static_Predicate and Dynamic_Predicate
+may be used to define properties of subtypes. A @i<predicate specification> is an
+@fa<aspect_specification> for one of the two predicate aspects.
+General rules for aspects and @fa<aspect_specification>s are found in
+Clause 13 (13.1 and 13.1.1 respectively).
+@dby
+The language-defined @i<predicate aspects> Static_Predicate and Dynamic_Predicate
+may be used to define properties of subtypes. A @i<predicate specification> is an
+@fa<aspect_specification> for one of the two predicate aspects.
+General rules for aspects and @fa<aspect_specification>s are found in
+Clause 13 (13.1 and 13.1.1 respectively). The predicate
+aspects are assertion aspects (see 11.4.2).
+
+
+!corrigendum 6.1.1(1/4)
+
+@drepl
+For a noninstance subprogram, a generic subprogram, or an entry, the
+following language-defined aspects may be specified with
+an @fa<aspect_specification> (see 13.1.1):
+@dby
+For a noninstance subprogram (including a generic formal subprogram), a 
+generic subprogram, an entry, or an access-to-subprogram type, the
+following language-defined assertion aspects may be specified with
+an @fa<aspect_specification> (see 13.1.1):
+
+
+!corrigendum 7.3.2(1/4)
+
+@drepl
+For a private type, private extension, or interface, the following
+language-defined aspects may be specified with an @fa<aspect_specification>
+(see 13.1.1):
+@dby
+For a private type, private extension, or interface, the following
+language-defined assertion aspects may be specified with an 
+@fa<aspect_specification> (see 13.1.1):
+
+!corrigendum 7.3.3(0)
+
+@dinsc
+See the conflict file for the changes.
+
+
+!corrigendum 9.5(17)
+
+@dinsa
+See the conflict file for the changes.
+
+
+!corrigendum 11.4.2(9/3)
+
+@drepl
+The @i<assertion_>@fa<aspect_mark> of a @fa<pragma> Assertion_Policy shall be
+one of Assert, Static_Predicate, Dynamic_Predicate, Pre, Pre'Class, Post,
+Post'Class, Type_Invariant, Type_Invariant'Class, or some
+implementation defined @fa<aspect_mark>. The @i<policy_>@fa<identifier>
+shall be either Check, Ignore, or some implementation-defined @fa<identifier>.
+@dby
+The @i<assertion_>@fa<aspect_mark> of a @fa<pragma> Assertion_Policy shall 
+identify an @i<assertion aspect>, namely
+one of Assert, Static_Predicate, Dynamic_Predicate, Pre, Pre'Class, Post,
+Post'Class, Type_Invariant, Type_Invariant'Class, Default_Initial_Condition,
+or some implementation-defined (assertion) @fa<aspect_mark>. The 
+@i<policy_>@fa<identifier> shall be either Check, Ignore, or some 
+implementation-defined @fa<identifier>.
+
+!corrigendum 11.4.2(10.2/3)
+
+@drepl
+A @fa<pragma> Assertion_Policy applies to the named assertion aspects in a
+specific region, and applies to all assertion expressions specified
+in that region. A @fa<pragma>
+Assertion_Policy given in a @fa<declarative_part> or immediately within a
+@fa<package_specification> applies from the place of the pragma to the end of
+the innermost enclosing declarative region. The region for a @fa<pragma>
+Assertion_Policy given as a configuration pragma is the declarative
+region for the entire compilation unit (or units) to which it applies.
+@dby
+A @fa<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. A @fa<pragma>
+Assertion_Policy given in a @fa<declarative_part> or immediately within a
+@fa<package_specification> applies from the place of the pragma to the end of
+the innermost enclosing declarative region. The region for a @fa<pragma>
+Assertion_Policy given as a configuration pragma is the declarative
+region for the entire compilation unit (or units) to which it applies.
+
+
+!corrigendum 13.1(8/3)
+
+@drepl
+A representation item @i<directly specifies> a @i<representation aspect> of
+the entity denoted by the @fa<local_name>, except in the case of a type-related
+representation item, whose @fa<local_name> shall denote a first subtype, and
+which directly specifies an aspect of the subtype's type. A representation item
+that names a subtype is either @i<subtype-specific> (Size and Alignment clauses)
+or @i<type-related> (all others). Subtype-specific aspects may differ for
+different subtypes of the same type.
+@dby
+A representation item @i<directly specifies> a @i<representation aspect> of
+the entity denoted by the @fa<local_name>, except in the case of a type-related
+representation item, whose @fa<local_name> shall denote a first subtype, and
+which directly specifies an aspect of the subtype's type. A representation item
+that names a subtype is either @i<subtype-specific> (Size, Object_Size, and
+Alignment clauses) or @i<type-related> (all others). Subtype-specific aspects 
+may differ for different subtypes of the same type.
+
+!corrigendum 13.1(9.1/4)
+
+@dinsa
+An operational item that directly specifies an aspect of an entity shall
+appear before the entity is frozen (see 13.14).
+@dinst
+An @fa<expression> or @fa<name> that freezes an entity shall not occur within
+an @fa<aspect_specification> that specifies a representation or operational
+aspect of that entity.
+
+!corrigendum 13.1(9.3/5)
+
+@drepl
+If a representation item, operational item, or @fa<aspect_specification> is given
+that directly specifies an aspect of an entity, then it is illegal to give
+another representation item, operational item, or @fa<aspect_specification> that
+directly specifies the same aspect of the entity.
+@dby
+If a representation item, operational item, library unit pragma (see 10.1.5),
+or @fa<aspect_specification> is given that directly specifies an aspect of an
+entity, then it is illegal to give another representation item, operational 
+item, library unit pragma, or @fa<aspect_specification> that directly specifies
+the same aspect of the entity.
+
+!corrigendum 13.1(11/3)
+
+@drepl
+Operational and representation aspects of a generic formal parameter are the
+same as those of the actual. Operational and representation aspects
+are the same for all views of a type. Specification of a type-related
+representation aspect is not allowed for a descendant of a generic formal
+untagged type.
+@dby
+If a type-related aspect is defined for the partial view of a type,
+then it has the same definition for the full view of the type.
+Type-related aspects cannot be specified, and are not
+defined for an incomplete view of a type. Representation aspects of a 
+generic formal parameter are the same as those of the actual. Specification
+of a type-related representation aspect is not allowed for a descendant of 
+a generic formal untagged type.
+
+!comment 13.1(13/3)
+!comment 13.1(15.1/3)
+!comment 13.1(18.1/3)
+!comment 13.1(18.2/3)
+!comment 13.1(18.3/5)
+
+!corrigendum 13.1.1(18.1/4)
+
+@dinsa
+If an aspect of a derived type is inherited from an ancestor type and has the
+boolean value True, the inherited value shall not be overridden to have the
+value False for the derived type, unless otherwise specified in this
+International Standard.
+@dinst
+If a given aspect is type-related and inherited, then within an
+@fa<aspect_definition> for the aspect, if a @fa<name> resolves to denote
+multiple visible subprograms, all or none of the denoted subprograms
+shall be primitives of the associated type.
+
+!corrigendum 13.1.1(18.3/4)
+
+@drepl
+If a nonoverridable aspect is directly specified for a type @i<T>, then any
+explicit specification of that aspect for any other descendant of @i<T>
+shall be @i<confirming>; that is, the specified @fa<name> shall @i<match>
+the inherited aspect, meaning that the specified @fa<name> shall denote the
+same declarations as would the inherited @fa<name>.
+@dby
+If a nonoverridable aspect is directly specified for a type @i<T>, then any
+explicit specification of that aspect for any descendant of @i<T>
+(other than @i<T> itself) shall be @i<confirming>. In the case of an aspect
+that is a @fa<name>, this means that the specified @fa<name> shall @i<match>
+the inherited aspect in the sense that it shall denote the same declarations
+as would the inherited @fa<name>. Similarly, for an
+aspect that is an @fa<expression> or an @fa<aggregate>, confirming means the
+defining @fa<expression> is fully conformant (see 6.3.1) with the defining
+@fa<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.
+
+
+!corrigendum 13.13.2(37/1)
+
+@dinsa
+In the default implementation of Read and Input for a type, End_Error is raised
+if the end of the stream is reached before the reading of a value of the type
+is completed.
+@dinst
+The Nonblocking aspect is statically True 
+and the Global aspect is @b<null> for the default implementations of 
+stream-oriented attributes for elementary types. For the default 
+implementations of stream-oriented attributes for composite types, the 
+value of the Nonblocking aspect is that of the first subtype, and
+the Global aspect defaults to that of the first subtype. A 
+default implementation of a stream-oriented attribute that has the 
+Nonblocking aspect statically True is considered a nonblocking region.
+The aspect Dispatching (see H.7.1) is Read(Stream) for the default 
+implementations of the stream-oriented attributes Read, Read'Class,
+Input, and Input'Class; the aspect Dispatching is Write(Stream) for
+the default implementations of the stream-oriented attributes Write,
+Write'Class, Output, and Output'Class.
+
+
+!corrigendum 13.14(7.2/3)
+
+@drepl
+@xbullet<At the freezing point of the entity associated with an
+@fa<aspect_specification>, any @fa<expression>s or @fa<name>s within the
+@fa<aspect_specification> cause freezing. Any static expressions within an
+@fa<aspect_specification> also cause freezing at the end of the immediately
+enclosing declaration list.>
+@dby
+At the freezing point of the entity associated with an
+@fa<aspect_specification>, any static expressions within the
+@fa<aspect_specification> cause freezing, as do @fa<expression>s or @fa<name>s in
+@fa<aspect_definition>s for representation aspects, or operational aspects
+that have a corresponding operational attribute. Any static
+expressions within an @fa<aspect_specification> also cause freezing at the
+end of the immediately enclosing declaration list. 
+
+!corrigendum 13.14(15.1/3)
+
+@dinsa
+@xbullet<At the place where a specific tagged type is frozen, the primitive
+subprograms of the type are frozen. At the place where a type is frozen, any
+subprogram named in an @fa<attribute_definition_clause> for the type is frozen.>
+@dinst
+@xbullet<At the place where a construct causes freezing, if the construct
+includes a check associated with some assertion aspect (independent of 
+whether the check is enabled), or depends on the definition of some 
+operational aspect as part of its Dynamic Semantics, any @nt{name}s or
+@nt{expression}s in the @nt{aspect_definition} for the
+aspect cause freezing.>
+    
 !ASIS
 
 No ASIS effect.
@@ -455,6 +714,25 @@
 
 !appendix
 
+[From Jeff Cousins AARM review - October 2020 - Editor.]
+
+13.1 (29.p/3) Aspects can now be specified for generic formals under AI12-0064-2 
+for Nonblocking, AI12-0272 for preconditions and AI12-0282 for atomic, presumably
+need to add something under “Extensions to Ada 2012”.
+
 ****************************************************************
+
+[From the Editor - November 24, 2020]
+
+The rewording for 13.13.2(37.1/5) had the wrong value for Nonblocking for
+elementary stream attributes. The Dispatching aspect takes care of any
+Nonblocking information from the dispatching calls, and any other code
+must be nonblocking. I reorganized the wording description to be a replacement,
+since it completely changes the meaning of the previous wording (showing 
+changes when switching the meaning 180 degrees is more confusing than 
+helpful).
+
+****************************************************************
+
 
 

Questions? Ask the ACAA Technical Agent