!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; -- 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. !corrigendum 6.5.1(3.3/3) @drepl @xindent shall be a static expression. This aspect is never inherited; if not directly specified, the aspect is False.> @dby @xindent 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) @drepl 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 @fas 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 @fa or operational item that specifies the same aspect of the type. @dby 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 @fas 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 @fa 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: @xbullet @xbullet:> @xinbull denotes one or more primitive subprograms of the type, the inherited aspect is a @fa that denotes the corresponding primitive subprogram(s) of the derived type;> @xinbull that denotes the same entity or entities as the original aspect;> @xbullet @xbullet or an @fa, the inherited aspect is a corresponding @fa or @fa where each @fa, 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 ****************************************************************