!standard 6.5.1(3.3/3) 20-01-21 AI12-0423-1/02 !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; -- what is the value of No_Return aspect of Pkg2.P ? 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. !ASIS No ASIS effect. !ACATS test An ACATS B-Test could be constructed out 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 ****************************************************************