Version 1.5 of ai12s/ai12-0396-1.txt

Unformatted version of ai12s/ai12-0396-1.txt version 1.5
Other versions for file ai12s/ai12-0396-1.txt

!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 9.5(53/5)
!standard 11.4.2(9/3)
!standard 11.4.2(10.2/3)
!standard 13.1(8/3)
!standard 13.1(9.1/5)
!standard 13.1(9.3/5)
!standard 13.1(11/3)
!standard 13.1(13/3)
!standard 13.1(15.1/3)
!standard 13.1(18.1/3)
!standard 13.1(18.2/3)
!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)
!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
!difficulty Medium
!subject Fixups for various aspects of aspects
!summary
Many of the rules in 13.1 apply only to representation aspects or only to type-related aspects. The freezing rules and "confirming" are clarified for aspects that are not values. The meaning of "inheritance" is clarified for all type-related aspects. Aspects of default stream attributes are defined.
!question
(1) We have various rules relating to aspects that are overly strict for certain aspects. In particular, the following rules are overly strict in some cases:
* (a) the rule in RM 13.1(11/3) that requires aspects to be the same for all views of a type;
* (b) the rule, also in 13.1(11/3), that requires the aspect of a formal and an actual generic to be the same; and
* (c) the rule in RM 13.1(9.1/5), and a related rule in RM 13.14(7.2/3) disallowing an aspect to contain an expression or name that causes freezing of the associated entity.
Should we fix the wording to relax the rules somewhat? (Yes.)
(2) The notion of "inheritance" is important for any type-related or subtype-specific aspect. For aspects of any other sort of entity, we should probably avoid the term. In particular, for aspects of primitive subprograms, when the subprogram is inherited, the semantics of such aspects can come from the usual implicit-conversion-and-call semantics, or can be defined as "applying" to overridings, as with Pre'Class and Post'Class, presuming the semantics are additive (rather than replacement based). Should these distinctions be clarified? (Yes.)
(3) Even for type-related aspects, there are cases where the aspect is inherited and can be overridden, other cases where the ("nonoverridable") aspect is inherited (possibly with some altered interpretation) and cannot be overridden except with a "matching" name or expression, and a third case where the aspect applies to descendant types, even if the descendant type defines its own name or expression for the aspect. Should we clarify these cases, and in particular 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 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 entity (typically its parent or progenitor or underlying subtype). By contrast, in RM 13.1.1, we typically use the term "specified" to mean that an aspect is defined within an aspect_specification for a given entity. Should we clarify how these two uses of the term "specified" are 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 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 enshrine the term "assertion aspect" which is used somewhat informally in 11.4.2, as a third kind of aspect, where all assertion aspects represent a boolean expression that is evaluated at various points as part of some operation associated with the entity. Should we consider adding a third kind of aspect, on top of "representation" and "operational"? (No.)
(6) The default stream attributes need to have well defined aspects, right? (Yes.)
!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 freezing rules for representation and operational aspects.
(1a) The rule about all views of a type should probably be made more explicit, to distinguish partial views, full views, formal type views, incomplete views, etc. The only critical rule seems to be that if a type-related aspect is defined on both a partial view and on a full view of the same type, it has the same definition. Incomplete views don't have any aspects to worry about.
(1b) The rule about generic formal/actual matching seems somewhat unnecessary, and might be dropped completely. Clearly we want attributes to return the same value on a formal as on the actual, but for aspects that do not have corresponding attributes, we don't seem to need any general rule. And it should perhaps talk about what happens in an instance, at which point the rule almost becomes a tautology since the actual has been substituted for the formal. Overall, it is not clear where this rule matters. Ultimately, we have decided to limit it to representation aspects.
(1c) The rules about freezing, in particular RM 13.14(7.2/3), should be revised to say that aspects that are names or expressions (as opposed to values) do not necessarily cause freezing when the associated entity is frozen. Of course, if we say that, we need to say exactly when they do cause freezing. Presumably pre/post cause freezing on a call. Type invariant causes freezing at any point where the type invariant would be relevant presuming the relevant policy is Check. A subtype predicate presumably causes freezing upon a membership test or assignment that would check the predicate (if the policy were Check), but it is fine if it uses the type name in a way that freezes the type that is currently being frozen.
(2-4) are all about clarification, and we will propose wording below that hopefully clarifies each of these cases.
(5) Adding a third kind of aspect only makes sense if the distinction is easy to make, and we simplify various rules by introducing it. In this AI we choose to preserve the main split between representation and operational, and then also define "assertion aspect" as a special kind of operational aspect.
(6) We clarify the aspects of default stream attribute implementations.
!wording
Modify 3.2.4(1/3):
The language-defined predicate aspects Static_Predicate and Dynamic_Predicate may be used to define properties of subtypes. A 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).}
Modify 6.1.1(1/5):
For a noninstance subprogram [Redundant:(including a generic formal subprogram)], a generic subprogram, or an entry, or an access-to-subprogram type, the following language-defined {assertion} aspects may be specified with an aspect_specification (see 13.1.1):
Modify 7.3.2(1/4):
For a private type, private extension, or interface, the following language-defined {assertion} aspects may be specified with an aspect_specification (see 13.1.1):
Modify 7.3.3(1/5):
For a private type or private extension (including a generic formal type), the following language-defined {assertion} aspect 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 first subtype of the full view of a type that has a partial [or incomplete] view. {If the Nonblocking aspect of the full view is inherited, it shall have the same value as that of the partial view.}
Modify 11.4.2(9/3):
The /assertion_/aspect_mark of a pragma Assertion_Policy shall [be] {identify an /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)} aspect_mark. The policy_identifier shall be either Check, Ignore, or some implementation-defined identifier.
{AARM To Be Honest: "Assert" is considered an "assertion aspect" for the purposes of this rule, even though there is no sort of entity that has an Assert aspect. It can only be specified using an Assert pragma, and applies to a particular point in the execution of a logical thread of control.}
Modify 11.4.2(10.2/3):
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.
Modify 13.1(8/3):
A representation item directly specifies a representation aspect of the entity denoted by the local_name, except in the case of a type-related representation item, whose 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 subtype-specific (Size{, Object_Size,} and Alignment clauses) or type-related (all others). [Redundant:Subtype-specific aspects may differ for different subtypes of the same type.]
Add after AARM 13.1(8.aa):
* Object_Size clause
Delete 13.1(9.1/5) [this was moved to 13.1.1]
Modify 13.1(9.3/5):
If a representation item, operational item, {library unit pragma (see 10.1.5),} or 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 aspect_specification that directly specifies the same aspect of the entity.
Modify 13.1(11/3):
{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 [Redundant: cannot be specified, and] are not defined for an incomplete view of a type.} [Operational and r]{R}epresentation 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.
{AARM Proof: The syntax of incomplete_type_declarations and formal_incomplete_type_declarations do not allow for an 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):
{The specification of certain language-defined aspects need not be supported by all implementations; in such an implementation, the specification for such an aspect}[If a specification of a representation or operational aspect is not supported by the implementation, it] is illegal or raises an exception at run time.
{AARM Ramification: There is an Implementation Permission below that allows an implementation to put restrictions on any representation aspect; this rule applies if that permission is used for an aspect. This rule only applies to an operational aspect if the aspect explicitly allows the aspect to not be supported.}
Modify 13.1(15.1/3):
In contrast, whether {type-related} operational aspects are inherited by a derived type depends on each specific aspect; unless specified, an operational aspect is not inherited. When {type-related} operational aspects are inherited by a derived type, aspects that were directly specified by aspect_specifications or operational items that are visible at [the]{any} point {within the immediate scope} of the derived type declaration, or (in the case where the parent is derived) that were inherited by the parent type from the grandparent type{,} are inherited. An inherited operational aspect is overridden by [a subsequent]{an} aspect_specification or operational item that specifies the same aspect of the type.
{AARM Reason: Unlike representation aspects, operational aspects can be inherited at any point in the immediate scope, and can be overridden by aspect_specifications or operational items that occur at a point before or after the inheritance takes place.}
Add after 13.1(15.1/3):
When a type-related operational aspect is inherited, the rules for inheritance depend on the nature of the aspect (see 13.1.1). Unless otherwise specified for a given aspect, these rules are as follows:
* For an operational aspect that is a value, the inherited aspect has the same value;
* For an operational aspect that is a name:
* 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 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 each name that denotes a primitive subprogram of the type denotes the corresponding primitive subprogram of the derived type, and where any other name denotes the same entity as that in the original aspect;
* For an operational aspect that is an identifier specific to the aspect, the inherited aspect is the same identifier.
Modify 13.1(18.1/3):
If an operational aspect is /specified/ for an entity (meaning that it is either directly specified or{, if type-related or subtype-specific,} inherited), then that aspect of the entity is as specified. Otherwise, the aspect of the entity has the default value for that aspect. {[Redundant: For aspects that are neither type-related nor subtype-specific, the terms "specified" and "directly specified" are equivalent.]}
{AARM Proof: Aspect inheritance is only defined for types and subtypes.}
Modify 13.1(18.2/3)
An aspect_specification or representation item that specifies a representation aspect that would have been chosen in the absence of the aspect_specification or representation item is said to be /confirming/. The aspect value specified in this case is said to be a confirming representation aspect value. Other values of the aspect are said to be nonconfirming, as are the aspect_specifications and representation items that specified them. {Similarly, an aspect_specification or operational item that specifies an operational 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(13/3):
An expression or name that causes freezing of an entity shall not occur within an aspect_specification that specifies a representation or operational aspect of that entity.
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 any explicit specification of that aspect for any other descendant of T (other than T itself) shall be confirming. In the case of an aspect [whose value]{that} is a name, this means that the specified name shall match the inherited aspect in the sense that it shall denote the same declarations as would the inherited name. {Similarly, for an aspect that is an expression or an aggregate, confirming means the defining expression is fully conformant (see 6.3.1) with the defining 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 nonoverridable aspect, they all have to specify the same or matching values for that aspect. Otherwise, we'd have two different values for 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}.
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 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.
AARM Ramification: If the default implementation of a stream-oriented attribute A for a composite type would call other stream-oriented attribute(s) whose Global aspect was not allowed by the Global aspect of A, then the Legality Rules of 6.1.2 are violated and the type declaration is illegal. If the stream-oriented attribute A is overridden, then the default implementation is not created and this check is not made. A similar ramification applies to the Nonblocking aspect of default implementation of a stream-oriented attribute.
Modify 13.14(7.2/3):
At the freezing point of the entity associated with an aspect_specification, any {static} expressions [or names] within the aspect_specification cause freezing{, as do expressions or names in aspect_definitions for representation aspects, or operational aspects that have a corresponding operational attribute.} Any static expressions within an aspect_specification also cause freezing at the end of the immediately enclosing declaration list.
Add after 13.14(15.1/3):
* At the place where a construct causes freezing, if the construct includes a check associated with some assertion aspect [Redundant: (independent of whether the check is enabled)], or depends on the definition of some operational aspect as part of its Dynamic Semantics, any names or expressions in the aspect_definition for the aspect cause freezing.
AARM Ramification: Aspects such as Constant_Indexing cause freezing when they are used -- the name in a Constant_Indexing would cause freezing when a generalized_indexing that makes use of it causes freezing.
!discussion
We have chosen to define a notion of an "assertion aspect" but we chose 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 do not apply to them.
There are clear reasons for restricting representation aspects, because having multiple representations can impose significant implementation burdens, and may not make sense at all. On the other hand, operational aspects might differ depending on the "view" of the type, so we permit, for example, generic formal types to impose additional checks when used inside the generic. Similarly, freezing rules need not be the same between representation aspects and other aspects, so we defer freezing in general until the operational aspect is needed, unless there is an associated attribute. Static expressions still are evaluated and cause freezing at an earlier point, because they can affect overload resolution (e.g. when used as the index in a 'First attribute).
We now define what inheritance means for all kinds of (inheritable) type-related aspects, as well as what it means to "confirm" an inherited type-related aspect. As part of this, we generally define inheritance of a name, or a more complex aspect that contains a name, such that if it denotes a primitive subprogram of the associated type, the name in the inherited aspect denotes the corresponding primitive subprogram, while if it denotes any other sort of thing, the name in the inherited aspect continues to denote the same thing. At one point we considered having a special case for names that denote subprograms that were not primitives, to provide automatic conversions on certain parameters much like what is done for primitives. But in the end that idea just seemed overly complicated.
We try to clarify the use of the word "specified", and indicate that "specified" and "directly specified" are synonyms when applied to aspects that are neither type related nor subtype specific, because there is no inheritance for such aspects.
!corrigendum 3.2.4(1/3)
Replace the paragraph:
The language-defined predicate aspects Static_Predicate and Dynamic_Predicate may be used to define properties of subtypes. A 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).
by:
The language-defined predicate aspects Static_Predicate and Dynamic_Predicate may be used to define properties of subtypes. A 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).
!corrigendum 6.1.1(1/4)
Replace the paragraph:
For a noninstance subprogram, a generic subprogram, or an entry, the following language-defined aspects may be specified with an aspect_specification (see 13.1.1):
by:
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 aspect_specification (see 13.1.1):
!corrigendum 7.3.2(1/4)
Replace the paragraph:
For a private type, private extension, or interface, the following language-defined aspects may be specified with an aspect_specification (see 13.1.1):
by:
For a private type, private extension, or interface, the following language-defined assertion aspects may be specified with an aspect_specification (see 13.1.1):
!corrigendum 7.3.3(0)
Insert new clause:
See the conflict file for the changes.
!corrigendum 9.5(17)
Insert after the paragraph:
See the conflict file for the changes.
!corrigendum 11.4.2(9/3)
Replace the paragraph:
The assertion_aspect_mark of a 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 aspect_mark. The policy_identifier shall be either Check, Ignore, or some implementation-defined identifier.
by:
The assertion_aspect_mark of a pragma Assertion_Policy shall identify an 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) aspect_mark. The policy_identifier shall be either Check, Ignore, or some implementation-defined identifier.
!corrigendum 11.4.2(10.2/3)
Replace the paragraph:
A pragma Assertion_Policy applies to the named assertion aspects in a specific region, and applies to all assertion expressions specified in that region. A pragma Assertion_Policy given in a declarative_part or immediately within a package_specification applies from the place of the pragma to the end of the innermost enclosing declarative region. The region for a pragma Assertion_Policy given as a configuration pragma is the declarative region for the entire compilation unit (or units) to which it applies.
by:
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. A pragma Assertion_Policy given in a declarative_part or immediately within a package_specification applies from the place of the pragma to the end of the innermost enclosing declarative region. The region for a 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)
Replace the paragraph:
A representation item directly specifies a representation aspect of the entity denoted by the local_name, except in the case of a type-related representation item, whose 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 subtype-specific (Size and Alignment clauses) or type-related (all others). Subtype-specific aspects may differ for different subtypes of the same type.
by:
A representation item directly specifies a representation aspect of the entity denoted by the local_name, except in the case of a type-related representation item, whose 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 subtype-specific (Size, Object_Size, and Alignment clauses) or type-related (all others). Subtype-specific aspects may differ for different subtypes of the same type.
!corrigendum 13.1(9.3/5)
Replace the paragraph:
If a representation item, operational item, or aspect_specification is given that directly specifies an aspect of an entity, then it is illegal to give another representation item, operational item, or aspect_specification that directly specifies the same aspect of the entity.
by:
If a representation item, operational item, library unit pragma (see 10.1.5), or 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 aspect_specification that directly specifies the same aspect of the entity.
!corrigendum 13.1(11/3)
Replace the paragraph:
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.
by:
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.
!corrigendum 13.1(13/3)
Replace the paragraph:
If a specification of a representation or operational aspect is not supported by the implementation, it is illegal or raises an exception at run time.
by:
The specification of certain language-defined aspects need not be supported by all implementations; in such an implementation, the specification for such an aspect is illegal or raises an exception at run time.
!corrigendum 13.1(15.1/3)
Replace the paragraph:
In contrast, whether operational aspects are inherited by a derived type depends on each specific aspect; unless specified, an operational aspect is not inherited. When operational aspects are inherited by a derived type, aspects that were directly specified by aspect_specifications or operational items that are visible at the point of the derived type declaration, or (in the case where the parent is derived) that were inherited by the parent type from the grandparent type are inherited. An inherited operational aspect is overridden by a subsequent aspect_specification or operational item that specifies the same aspect of the type.
by:
In contrast, whether type-related operational aspects are inherited by a derived type depends on each specific aspect; unless specified, an operational aspect is not inherited. When type-related operational aspects are inherited by a derived type, aspects that were directly specified by aspect_specifications or operational items that are visible at any point within the immediate scope of the derived type declaration, or (in the case where the parent is derived) that were inherited by the parent type from the grandparent type, are inherited. An inherited operational aspect is overridden by an aspect_specification or operational item that specifies the same aspect of the type.
When a type-related operational aspect is inherited, the rules for inheritance depend on the nature of the aspect (see 13.1.1). Unless otherwise specified for a given aspect, these rules are as follows:
!corrigendum 13.1(18.1/3)
Replace the paragraph:
If an operational aspect is specified for an entity (meaning that it is either directly specified or inherited), then that aspect of the entity is as specified. Otherwise, the aspect of the entity has the default value for that aspect.
by:
If an operational aspect is specified for an entity (meaning that it is either directly specified or, if type-related or subtype-specific, inherited), then that aspect of the entity is as specified. Otherwise, the aspect of the entity has the default value for that aspect. For aspects that are neither type-related nor subtype-specific, the terms "specified" and "directly specified" are equivalent.
!corrigendum 13.1(18.2/3)
Replace the paragraph:
An aspect_specification or representation item that specifies a representation aspect that would have been chosen in the absence of the aspect_specification or representation item is said to be confirming. The aspect value specified in this case is said to be a confirming representation aspect value. Other values of the aspect are said to be nonconfirming, as are the aspect_specifications and representation items that specified them.
by:
An aspect_specification or representation item that specifies a representation aspect that would have been chosen in the absence of the aspect_specification or representation item is said to be confirming. The aspect value specified in this case is said to be a confirming representation aspect value. Other values of the aspect are said to be nonconfirming, as are the aspect_specifications and representation items that specified them. Similarly, an aspect_specification or operational item that specifies an operational aspect to be the same as the definition it would have by default is said to be confirming; otherwise it is nonconfirming.
!corrigendum 13.1.1(13/3)
Insert after the paragraph:
If the first freezing point of the associated entity comes before the end of the immediately enclosing declaration list, then each usage name in the aspect_definition shall resolve to the same entity at the first freezing point as it does at the end of the immediately enclosing declaration list.
the new paragraph:
An expression or name that causes freezing of an entity shall not occur within an aspect_specification that specifies a representation or operational aspect of that entity.
!corrigendum 13.1.1(18.1/4)
Insert after the paragraph:
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.
the new paragraph:
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.
!corrigendum 13.1.1(18.3/4)
Replace the paragraph:
If a nonoverridable aspect is directly specified for a type T, then any explicit specification of that aspect for any other descendant of T shall be confirming; that is, the specified name shall match the inherited aspect, meaning that the specified name shall denote the same declarations as would the inherited name.
by:
If a nonoverridable aspect is directly specified for a type T, then any explicit specification of that aspect for any descendant of T (other than T itself) shall be confirming. In the case of an aspect that is a name, this means that the specified name shall match the inherited aspect in the sense that it shall denote the same declarations as would the inherited name. Similarly, for an aspect that is an expression or an aggregate, confirming means the defining expression is fully conformant (see 6.3.1) with the defining 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)
Insert after the paragraph:
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.
the new paragraph:
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 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)
Replace the paragraph:
by:
At the freezing point of the entity associated with an aspect_specification, any static expressions within the aspect_specification cause freezing, as do expressions or names in aspect_definitions for representation aspects, or operational aspects that have a corresponding operational attribute. Any static expressions within an aspect_specification also cause freezing at the end of the immediately enclosing declaration list.
!corrigendum 13.14(15.1/3)
Insert after the paragraph:
the new paragraph:
!ASIS
No ASIS effect.
!ACATS test
Most of these changes don't affect anything, simply make the rules more sensible. But it might be necessary to change some test cases in existing tests if the old rules were tested.
!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).

****************************************************************

[From the Editor - November 27, 2020]

We have in 13.1(9.1/5):
 
  An expression or name that causes freezing of an entity shall not 
  occur within an aspect_specification that specifies a representation 
  or operational aspect of that entity.

This rule is solely about aspect_specifications. It doesn't have anything to
do with aspects in general, or any representation or operational items. Rules
like that belong in 13.1.1 (the aspect_specification clause). So I'd suggest
moving this rule after 13.1.1(13/3) (which is also about freezing).

Tucker Taft replied:
That makes sense. Probably could be part of (13/3) rather than a new paragraph.

****************************************************************




Questions? Ask the ACAA Technical Agent