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

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

!standard 3.2.4(1/3)          20-09-03 AI12-0396-1/01
!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)
!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(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 work item 20-09-03
!status received 20-09-03
!priority Medium
!difficulty Medium
!subject Fixups for various aspects of aspects
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.
(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.)
(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.
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 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 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,
Modify 13.1(9.1/5):
An expression or name that {causes freezing of} [freezes] an entity shall not occur within an aspect_specification that specifies a representation or operational aspect of that entity.
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.}
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.
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 a primitive subprogram of the type, the inherited aspect is a name that denotes the corresponding primitive subprogram of the derived type;
* otherwise, the inherited aspect is a name that denotes the same entity 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.]}
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 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}.
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 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.
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 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.
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.


Questions? Ask the ACAA Technical Agent