Version 1.3 of ai12s/ai12-0423-1.txt
!standard 6.5.1(3.3/3) 20-01-26 AI12-0423-1/03
!standard 13.1(15.7/5)
!standard 13.1(15.8/5)
!class binding interpretation 20-01-19
!status Amendment 1-2012 21-01-21
!status ARG Approved 15-0-0 21-01-20
!status work item 20-01-19
!status received 20-01-19
!priority Low
!difficulty Easy
!qualifier Omission
!subject Aspect inheritance fixups
!summary
For an aspect that is an aggregate, each association inherits in the same way
as an aspect of the appropriate kind.
No_Return aspects are inherited from the subprogams of parent and progenitor
types.
!question
(1) 13.1(15.7/5) defines how the parts of an aspect that is an aggregate
are inherited. However, a part of an aggregate could also be a value or
an identifier specific to the aspect. It's odd that these sorts of things
are mentioned in the surrounding bullets but not in the aggregate inheritance
bullet.
(2) 6.5.1(3.3/3) says that the No_Return aspect is "never inherited". However,
in a case like:
package Pkg1 is
type T1 is tagged null record;
procedure P (X1 : T1) with No_Return;
end Pkg1;
package Pkg2 is
type T2 is new Pkg1.T1 with null record;
--
end Pkg2;
package Pkg3 is
type T3 is new Pkg2.T2 with null record;
overriding procedure P (X3 : T3) with No_Return => False;
end record;
The overriding of P for T3 is supposed to be illegal by 6.5.1(6/5) (else we
could dispatch to a routine that violates the aspect). But it
appears that the value of the No_Return aspect for Pkg2.P is False.
Should this be fixed? (Yes.)
!recommendation
(See Summary.)
!wording
Modify 6.5.1(3.3/3):
If directly specified, the aspect_definition shall be a static expression.
{When not directly specified, if the subprogram is primitive subprogram
inherited by a derived type, then the aspect is True if any corresponding
subprogram of the parent or progenitor types is nonreturning. Otherwise,}
[This aspect is never inherited; if not directly specified,] the aspect is
False.
Modify 13.1(15.7-8/5):
{* For an operational aspect that is an identifier specific to the aspect,
the inherited aspect is the same identifier;}
* For an operational aspect that is an expression or an aggregate, the
inherited aspect is a corresponding expression or aggregate where each
{name, value, and identifier follows these same rules for
inheritance.}[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.]
[Author's note: This reverses the order of the bullets and makes the last
bullet recursive.]
!discussion
(1) It makes more sense to make the rules recursive than to repeat the rules
for expressions and aggregates. That avoids subtle differences in wording and
possibly interpretation.
(2) It's best to ensure that the aspect is appropriately inherited. We don't
have any blanket rules for inheritance of subprogram aspects, so we just
define what we need here.
!corrigendum 6.5.1(3.3/3)
Replace the paragraph:
If directly specified, the aspect_definition shall be a static expression.
This aspect is never inherited; if not directly specified, the aspect is False.
by:
If directly specified, the aspect_definition shall be a static
expression. When not directly specified, if the subprogram is primitive
subprogram inherited by a derived type, then the aspect is True if any
corresponding subprogram of the parent or progenitor types is nonreturning.
Otherwise, the aspect is False.
!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:
- 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 identifier specific to the
aspect, the inherited aspect is the same identifier;
- For an operational aspect that is an expression or an
aggregate, the inherited aspect is a corresponding expression or
aggregate where each name, value, and identifier follows these same
rules for inheritance.
!ASIS
No ASIS effect.
!ACATS test
An ACATS B-Test could be constructed out of the example in question (2). For
question (1), no specific tests should be needed, general inhertance tests
for each aspect should sufficiently cover the rules.
!appendix
****************************************************************
Questions? Ask the ACAA Technical Agent