Version 1.1 of ai12s/ai12-0398-1.txt

Unformatted version of ai12s/ai12-0398-1.txt version 1.1
Other versions for file ai12s/ai12-0398-1.txt

!standard 3.5.1(3)          20-09-10 AI12-0398-1/01
!standard 3.7(5/2)
!standard 6.5(2.1/3)
!class Amendment 20-09-10
!status work item 20-09-10
!status received 20-09-09
!priority Low
!difficulty Easy
!subject Most declarations should have aspect specifications
Aspect_Specifications are added to extended return object declarations, discriminant specifications, and enumeration literals.
The majority of kinds of declarations of entities allow aspect specifications, along with most forms of bodies. This is important even beyond language-defined aspects so that implementation-defined aspects can be added to the declarations when necessary. This allows implementations to add capabilities that aren't common enough or well-defined enough to add to the Standard now, and allow experience to be gained for possible future standardization.
However, a few kinds of declaration do not, and at least some of those have plausible uses of implementation-defined aspects. We should allow aspect specifications on all declarations where that does not cause syntax or semantic problems and a directly enclosing entity does not provide an preferred alternative.
(See Summary.)
Replace 3.5.1(3) with:
enumeration_literal_specification ::= defining_identifier [aspect_specification] | defining_character_literal [aspect_specification]
Replace 3.7(5/2) with:
discriminant_specification ::= defining_identifier_list : [null_exclusion] subtype_mark [:= default_expression] [aspect_specification] | defining_identifier_list : access_definition [:= default_expression] [aspect_specification]
Replace 6.5(2.1/3) with:
extended_return_object_declaration ::= defining_identifier : [aliased][constant] return_subtype_indication [:= expression] [aspect_specification]
AARM 13.1(4.b/5) has a list of all declarations and whether or not they allow aspect specifications. Looking at each declaration that does not allow an aspect specification:
incomplete_type_declaration - NO:
According to AI12-0396-1, these do not even have aspects, and Legality Rules have long preventing reading aspects of an incomplete view via an attribute or setting them with an attribute_definition_clause. It makes no sense to set that which does not exist (and certainly cannot be used).
formal_incomplete_type_declaration - NO:
Same as incomplete_type_declaration; even when the actual is a concrete type, nothing can depend on the aspects of a formal incomplete type.
discriminant_specification - YES:
Similar declarations component_declarations and formal_parameters both allow aspect_specifications. Additionally, one could imagine a Position aspect that would allow using aspects to set positional information rather than needing to use a separate record_representation_clause. For this to be useful, it would need to work on both discriminants as well as regular components.
enumeration_literal_specification - YES:
Users already have proposed (see held AI12-0365-1) adding some way to directly specify representations of enumeration values rather than needing a separate enumeration_representation_clause which requires repeating all of the literals. While this is a need that will not be directly addressed in Ada 202x, providing an avenue for implementers to address this if their customers demand it seems valuable. And that could be done using an aspect, perhaps something like:
type Color is (Black with Rep => 0, Yellow with Rep => 1, Red with Rep => 2, Blue with Rep => 4, White with Rep => 7);
extended_return_object_declaration - YES:
Most properties of a return object need to be visible to the caller as well as the callee, and thus have to be declared for the function. However, properties that are not needed by the callee could and probably should be declared on the declaration of the return object.
We allow aspect specifications on program unit bodies for this reason, even though the language does not support any such aspects. The same probably ought to be true here.
chunk_specification - NO:
AI12-0355-2 adds an optional aspect_specification to parallel operation headers, so anywhere a chunk_specification can be used already has an aspect specification. Since only a single chunk_specification can be used, that aspect specification can unambigiously be used for any aspect that needs to apply to the chunk_specification. Moreover, allowing an aspect_specification on the chunk_specification as well would be confusing; the aspect_specification on the chunk parameter could only be used to modify that parameter but not the enclosing entity, while the other aspect_specification modifies the loop behavior. It would be very easy to misplace the aspect_specification if it was allowed in two adjacent places with subtly different associated entities.
iterated_component_association - NO:
This is specifically the loop parameter of traditional form of the array aggregate iterator. For this form, the loop parameter is a name for the usually declared choices (and those choices have to obey all of the usual rules for an array aggregate choice list, which is why this is a separate kind of iterator). As such, there are no properties of the loop parameter beyond those of the index subtype, so there does not appear to be anything plausible that an implementation could specify. Thus no aspect_specification is needed.
loop_parameter_specification - NO:
Like a choice parameter, this is naming something defined primarily by the implementation.
But the most important question here is whether we need in the future an aspect_specification on all loops. There seems to be a need for a way to support loop invariants using the aspect syntax, since we would want those to look consistent with other assertion contracts in the language. If we were to add such an aspect_specification, it could be used to control any aspects of the loop parameter, and moreover having multiple aspect specifications would be a source of confusion (just as it would be for a chunk_specification).
Note that there are other kinds of looping constructs in Ada 202x: aggregate elements of various kinds, quantified expressions, and reduction expressions. For consistency, all of these would need the same treatment as loops. That could cause syntax problems, especially for aggregates where "with" already as a meaning.
We definitely don't want loops with a large number of different places that allow aspect_specifications, all with subtly different associated entities.
It's probably too late for Ada 202x to work out all of these issues, and it's probably best to avoid adding any syntax unless we have a known need for it (since removing it later is usually a compatibility problem), so the author recommends holding off on this for now.
iterator_parameter_specification - NO:
These declarations are intended to provide a short-hand for accessing existing items. There doesn't seem to be much value to adding an aspect specification to a short-hand. Additionally, this is always associated with a loop, so the issues noted in the previous item also apply.
iterator_specification - NO:
These are the other forms of (loop) iterator, including the array and container iterators. In general, the details of the loop parameter are determined by the underlying array or container (since they are the cursors or elements of those containers). As such, there doesn't seem to any plausible uses for an aspect_specification for the loop parameter for these iterators.
Additionally, all of the discussion about the traditional loop_parameter_specification applies here as well. As such, we should wait on this until we have a demonstrated need for an aspect.
choice_parameter_specification - NO(?):
This appears in the list of an exception_handler. The author thinks that allowing an aspect_specification would cause confusing syntax as it would be easy to confuse "when" and "with" and both have choose symbols:
when Foo with Traceback => True : Bar_Error => ...;
There's no known plausible use for an aspect specification here, as well, given that the entity is naming something provided by the implementation that cannot be changed.
[Author's note: I'm not that sure about this one. Better arguments (either way) welcome.]
entry_index_specification - NO(?):
This serves a similar purpose to a parameter of a protected entry. However, it only applies to the body of the entry (the specification of the entry index is just a subtype without any declaration). That means that many uses of aspect_specifications are not possible: only private (non-representation) information can be changed. There doesn't seem to be any use for that.
[Author's note: The conclusion here is reverse that of extended returns, which have similar limitations. Assuming that aspect specs don't participate in conformance, there wouldn't be a problem allowing one here. I'm on the fence, additional opinions welcome.]
[Not sure. It seems like some new capabilities might be needed, but I didn't check - Editor.]
!ACATS test
As these are associated only with implementation-defined aspects, no useful tests can be constructed. A test checking that an implementation-defined aspect is not allowed on these constructs is the best that could be done, but that seems to be low value.

From: Randy Brukardt
Sent: Thursday, September 10, 2020  7:09 PM

Here's my homework from yesterday, an AI exploring all remaining kinds of 
declarations and considering whether we would want to allow an 
aspect_specification on them. [This is version /01 of the AI - Editor.]

I explored each individual declaration in the !discussion that currently does 
not allow an aspect_specification. They're roughly in order of certainty about
the Yes/No decision.

It would be nice to articulate a general principle: "aspect_specifications 
should be found on all declarations except those for incomplete views and ..." 
but I have not tried that.

Consider this version my opinion; I haven't show this to anyone yet. (The 
topic was previously discussed with Steve and Tucker, but the text here is
all mine.)

Comments welcome and encouraged.


Questions? Ask the ACAA Technical Agent