AI22-0032-1
!standard 4.3.5(11/5) 25-03-24 AI22-0032-1/05
!class binding interpretation 22-01-26
!status Amendment 1-2022 22-02-03
!status WG9 Approved 25-07-18
!status WG9 Approved 22-10-18
!status ARG Approved 16-0-0 22-02-03
!status work item 22-01-26
!status received 21-11-09
!submitter Randy Brukardt
!priority Low
!difficulty Easy
!qualifier Omission
!subject Abstract container aggregates
If the container type of an Aggregate aspect is not abstract, none of the subprograms specified in the Aggregate aspect can be abstract.
Nothing in 4.3.5 disallows a subprogram specified in an Aggregate aspect from being abstract. Obviously, we do not want an aggregate whose implementation would call an abstract subprogram (we never want to call an abstract subprogram). Is there a rule missing here? (Yes.)
(See Summary.)
Add after 4.3.5(11/5):
If the container type T is not abstract, then none of the subprograms specified in the Aggregate aspect for T shall be abstract.
AARM Ramification: Since the Aggregate aspect is nonoverridable, this rule is rechecked on any derived type that inherits an Aggregate aspect.
In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance of a generic unit.
AARM Ramification: The first Legality Rule has to be rechecked in instances, if a type with an Aggregate aspect is derived from a formal private type, in case the actual type for the private type is an array type. The last Legality Rule has to be rechecked in instances, in case an actual type for an abstract formal type is not abstract.
The rules for abstract operations make it illegal for a nonabstract tagged type to have any abstract operations. However, since the Aggregate aspect is allowed on any non-array type, abstract operations are possible if the type is not tagged. We surely do not want to have an aggregate calling abstract routines.
We also have a language design principle that if every use of some definition would be illegal, then the definition itself is illegal. (One example is a Pure generic unit; if no instantiation of the unit could be declared Pure, the generic unit is illegal.) This means we want the Aggregate aspect to be illegal if any container aggregate would be illegal by making illegal calls.
For all of these reasons, we need an explicit rule to ban abstract subprograms from being used in an Aggregate aspect for a nonabstract type. Note that we do not need an additional rule to ban this for any derived type that inherits the Aggregate aspect, as this aspect is nonoverridable, and the Legality Rules associated with a nonoverridable aspect are rechecked for each derived type that inherits the aspect (by 13.1.1(18.3/5)).
Note that it is OK to have abstract routines if the type itself is abstract; in that case, no aggregate can be written (as abstract aggregates are banned by 3.9.3(8/5)). It's unclear if this would be a useful construct, but since there is no semantic problem, there seems to be no reason to ban it.
@dinsa
For an Aggregate aspect, the key type of Assign_Indexed shall be the same
type as that of the parameters of New_Indexed. Additionally, if both
Add_Unnamed and Assign_Indexed are specified, the final parameters shall
be of the same type @emdash the element type of the container type.
@dinst
If the container type @i{T} is not abstract, then none of the subprograms
specified in the Aggregate aspect for @i{T} shall be abstract.
In addition to the places where Legality Rules normally apply (see @ref{12.3}),
these rules apply also in the private part of an instance of a generic unit.
ACATS B-Test(s) should check that this rule is enforced (including in the case of [untagged] derived types).
From: The Editor - February 4th, 2022
I happened to notice that the first Legality Rule of 4.3.5 also could need
rechecking in an instance. Therefore, I put the generic boilerplate into a
separate paragraph and split and updated the AARM note appropriately. Consider
this my editorial review.
****************************************************************