AI22-0127-1
!standard 10.2.1(25/5) 25-04-18 AI22-0127-1/03
!standard 13.1.1(32/5)
!class binding interpretation 25-01-27
!status Amendment 1-2022 25-01-27
!status WG9 Approved 25-07-18
!status ARG Approved 13-0-0 25-03-19
!status work item 25-01-27
!status received 25-01-27
!assigned author Randy Brukardt
!submitter Stephen Baird
!priority Medium
!difficulty Easy
!qualifier Omission
!subject Elaborate_Body is a library unit aspect
Elaborate_Body is a library unit aspect.
Library unit aspects cannot be specified on library_unit_renaming_declarations.
10.2 and 10.2.1 mention the Elaborate_Body aspect several times, but nowhere are the details of the aspect defined. What are they?
(See summary.)
Modify 10.2.1(25/5):
If the {library unit }aspect Elaborate_Body is True for a declaration, then the declaration requires a completion (a body).
Modify 13.1.1(32/5):
Some aspects are defined to be library unit aspects. Library unit aspects are of type Boolean. The expression specifying a library unit aspect shall be static. Library unit aspects are defined for all program units, but shall be specified only for library units{ that are not library_unit_renaming_declarations}. Notwithstanding what this document says elsewhere, the expression of a library unit aspect is resolved and evaluated at the point where it occurs in the aspect_specification, rather than the first freezing point of the associated unit.
The obsolescent pragma Elaborate_Body is a library unit pragma, so clearly the aspect should be a library unit aspect. It appears that was an oversight when the pragma was made obsolescent.
It might seem surprising that just adding two words to an existing Legality Rule is a sufficient definition for this aspect. However, that is how the aspects Pure and Preelaborate are defined, so it makes sense to do the same for this aspect. Note that 13.1.1 gives a detailed definition of the workings of library unit aspects, including that they are Boolean, static, and evaluated immediately, so there is no need to do that here.
A complaint has been raised that the aspect definitions are hard to find in 10.2.1. That is true, but the organization of the clause makes that the case. The main issue is that the old pragma definitions were easier to see. While that is true, they also carried no information beyond the fact that they were library unit pragmas and the pragma name (and used up a lot of screen space for that small amount of information). To find out anything about what the pragmas do, one has to scroll down twice to find the actual definition (which is mixed in with other semantics). We could do the same with the aspects, but it would look silly:
The following library unit aspect is defined:
Pure
As there is nothing to say at this point about what the aspect does. Putting the actual definition together with aspect definition in a traditional form would require a major restructuring of this subclause.
The lack of an obvious definition is not a major problem in finding the aspects; one typically would use the index or the aspect list to find the name of the aspect and subclause where it is defined. As such, we chose to just fix the bugs at this time. Perhaps a future revision will tackle the needed reorganization of 10.2.1, but doing so now would prevent fixing the bugs in time to include them in the forthcoming Corrigendum.
The first use of “library unit aspect” in 10.2.1 has a cross-reference to 13.1.1, so one is not needed here. Note that the Pure library unit aspect does not have a cross-reference, either.
In researching this fix, it was noted that library unit aspects are expected to be usable in the same ways as the library unit pragmas that they replace. However, the current wording for library unit aspects allow them to be specified on all library units (that are not completions, since completions are not allowed by 13.1.1(18/5)), while library unit pragmas were only allowed following library_unit_declarations excepting package declarations and inside of the visible part of library units.
As such, we have added wording to disallow specifying library unit aspects on library_unit_renaming_declarations (as they are not library_unit_declarations and have no visible part). Like all renamings, library unit renamings inherit their properties from the renamed library unit. The properties cannot be changed. We could have allowed confirming aspect specifications instead of disallowing them, but that would add a new complication for both the RM (matching wording would be needed) and implementations, for a feature that no one has asked for. As such, we choose the simpler fix.
Note that library unit aspects are allowed on library unit bodies that are not completions (that is, library subprogram bodies). This appears to be a new capability, but it is not, as it was always intended to be able to put the pragma inside such a unit (see AARM J.15(6.a/5)). [Author’s note: I don’t think it is actually legal to put a pragma in the visible part (that is, profile) of a library subprogram, but clearly the intent was that there would be a way to do this for library subprogram bodies. The AARM note was an original Ada 95 note in 10.1.5 moved to its current location by Ada 2022.]
@drepl
If the aspect Elaborate_Body is True for a declaration, then the declaration requires a completion (a body).
@dby
If the library unit aspect Elaborate_Body is True for a declaration, then the declaration requires a completion (a body).
@drepl
Some aspects are defined to be @i{library unit aspects}. Library unit aspects are of type Boolean. The expression specifying a library unit aspect shall be static. Library unit aspects are defined for all program units, but shall be specified only for library units. Notwithstanding what this document says elsewhere, the expression of a library unit aspect is resolved and evaluated at the point where it occurs in the @fa{aspect_specification}, rather than the first freezing point of the associated unit.
@dby
Some aspects are defined to be @i{library unit aspects}. Library unit aspects are of type Boolean. The expression specifying a library unit aspect shall be static. Library unit aspects are defined for all program units, but shall be specified only for library units that are not @fa{library_unit_renaming_declaration}s. Notwithstanding what this document says elsewhere, the expression of a library unit aspect is resolved and evaluated at the point where it occurs in the @fa{aspect_specification}, rather than the first freezing point of the associated unit.
ACATS B-Tests are needed to check that the rules associated with library unit aspects are enforced. (A test similar to BA21005 is needed.)
This issue was raised privately by Steve Baird.