Version 1.5 of ai12s/ai12-0398-1.txt
!standard 3.7(5/2) 20-10-21 AI12-0398-1/03
!standard 6.3.1(25)
!standard 6.5(2.1/3)
!standard 9.5.2(8)
!class Amendment 20-09-10
!status Amendment 1-2012 20-10-21
!status ARG Approved 13-0-1 20-10-21
!status work item 20-09-10
!status received 20-09-09
!priority Low
!difficulty Easy
!subject Most declarations should allow aspect specifications
!summary
Aspect_Specifications are added to extended return object declarations,
discriminant specifications, and entry index specifications.
!problem
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 allow aspect specification, 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 where a directly enclosing entity does
not provide a preferred alternative.
!proposal
(See Summary.)
!wording
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]
Add after 6.3.1(25):
NOTE: Any conformance requirements between aspect_specifications that are part
of a profile or known_discriminant_part are defined by the semantics of each
particular aspect. In particular, there is no general requirement for
aspect_specifications to match in conforming profiles or discriminant parts.
[Author's note: This covers both formal parameters (see AI12-0395-1) and
discriminant_specifications. The normative wording has the right effect
already, but users probably would be surprised by the omission of aspect
specifications from conformance.]
Replace 6.5(2.1/3) with:
extended_return_object_declaration ::=
defining_identifier : [aliased][constant] return_subtype_indication [:= expression] [aspect_specification]
Replace 9.5.2(8) with:
entry_index_specification ::= for defining_identifier in discrete_subtype_definition [aspect_specification]
Update the list in AARM 13.1.1(4.b/5) to reflect these changes.
!discussion
AARM 13.1(4.b/5) has a list of all declarations and whether or not they allow
aspect specifications. Most declarations already 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 prevented 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:
The similar constructs 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 discriminants as well as regular components.
entry_index_specification - YES:
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. Still, the motivating case for allowing
aspect_specifications on formal parameters was for aspect Unreferenced;
since the identifier is not optional here, such a use makes as much sense for
these as it does for a formal parameter. As such, we suggest that aspect
specifications be allowed here.
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.
enumeration_literal_specification - NO:
There are plausible uses for an aspect_specification on an
enumeration_literal_specification. For instance, 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.
This 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);
Unfortunately, an aspect_specification is a comma-delimited list, as is an
enumeration_type_definition. That makes the syntax ambiguous if
aspect_specifications are just added in the normal way. For example:
type Trouble is (OK with Rep => 0, Pack);
Here, is Pack a boolean aspect or is it a second enumeration literal?
A number of ways to work around this have been proposed (do not allow omitting
the => for such an aspect, allow only a single aspect specification, put the
aspect specification in parens), but all of them are more complex than simply
modifying the syntax to add an optional item. Moreover, we would need to know
the intended usage before we could decide which of the workarounds is best.
As such, we do nothing at this time.
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 unambiguously 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 the 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. 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 => ...;
Moreover, there's no known plausible use for an aspect specification here,
given that the entity is naming something provided by the implementation that
cannot be changed. Additionally, the name is optional, so Unreferenced is not
necessary on choice parameters (if you don't need the name, just omit it
completely).
!corrigendum 3.7(5/2)
Replace the paragraph:
discriminant_specification ::=
defining_identifier_list : [null_exclusion] subtype_mark [:= default_expression]
| defining_identifier_list : access_definition [:= default_expression]
by:
discriminant_specification ::=
defining_identifier_list : [null_exclusion] subtype_mark [:= default_expression] [aspect_specification]
| defining_identifier_list : access_definition [:= default_expression] [aspect_specification]
!corrigendum 6.3.1(25)
Insert after the paragraph:
An implementation may declare an operator declared in a language-defined library unit to be intrinsic.
the new paragraph:
NOTES
11 Any conformance requirements between aspect_specifications that are part
of a profile or known_discriminant_part are defined by the semantics of each
particular aspect. In particular, there is no general requirement for
aspect_specifications to match in conforming profiles or discriminant parts.
!corrigendum 6.5(2.1/3)
Replace the paragraph:
extended_return_object_declaration ::=
defining_identifier : [aliased][constant] return_subtype_indication [:= expression]
by:
extended_return_object_declaration ::=
defining_identifier : [aliased][constant] return_subtype_indication [:= expression] [aspect_specification]
!corrigendum 9.5.2(8)
Replace the paragraph:
entry_index_specification ::= for defining_identifier in discrete_subtype_definition
by:
entry_index_specification ::= for defining_identifier in discrete_subtype_definition [aspect_specification]
!ASIS
No ASIS change needed.
!ACATS test
As these are associated only with implementation-defined aspects, no useful
tests can be constructed. A test checking that an language-defined
aspect is not allowed on these constructs is the best that could be done, but
that seems to be very low value.
!appendix
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.
****************************************************************
From: Randy Brukardt
Sent: Thursday, September 10, 2020 6:14 PM
I was looking at extended aspect_specs to most of the remaining declarations,
and that brought up a question in my mind:
How does the presence/absence/contents of an aspect_specification affect
conformance?
Now that we are allowing aspect_specifications on formal parameters, they can
appear both in the declaration of a profile and in the body. Do they have to
match? Should they be ignored? Regardless of what we decide, shouldn't we say
*something* about this in 6.3.1?
The issue will also appear for discriminant_specifications, which is the most
no-brainer of the remaining types of declarations (aspect_specs are allowed on
regular components, so not allowing them on discriminants seems like a wart
rather than a feature).
A reminder that no good deed goes unpunished, or perhaps that there never
seems to be a trivial change. :-)
****************************************************************
From: Randy Brukardt
Sent: Thursday, September 10, 2020 6:40 PM
Looking at 6.3.1, it appears that aspect_specs are ignored for conformance
purposes. I think that ought to be made explicit if that is the intent, with
at a minimum a user note (nothing else in a profile is ignored).
It's probably OK to leave conformance to a case-by-case basis; it's critical
for some aspects (ones that select parameter representation, for instance) and
probably irrelevant for something like Unreferenced (the motivating case). But
implementers had better be aware that this is an issue.
Bad things would certainly happen with something like:
procedure P (A : My_Array with Simple => True);
procedure P (A : My_Array with Simple => False) is
...
where the representation used by a call and the body are different.
****************************************************************
From: Steve Baird
Sent: Thursday, September 10, 2020 6:52 PM
> How does the presence/absence/contents of an aspect_specification
> affect conformance?
That point is discussed in the !discussion section of the AI:
Implementations are, of course, responsible for defining the rules for
any implementation-defined aspect whose specification using this new
syntax is allowed (e.g., interactions with conformance rules,
interactions with defining_identifier_lists of length longer than
one).
> Regardless of what we decide, shouldn't we say *something* about this in
> 6.3.1?
Until the RM defines a language-defined aspect that uses this syntax, there is
no *requirement* for the RM to say anything about this. I agree that we could
add some RM wording on the subject, but I don't see a reason to do so.
****************************************************************
From: Randy Brukardt
Sent: Thursday, September 10, 2020 7:21 PM
I don't think that there is any other real case in Ada where some of the text
of a profile is completely ignored when considering conformance rules. I think
that deserves a user note at a minimum. Ignoring large blocks of text is
completely against the philosophy of Ada; if we believe it makes sense we
still need to explain ourselves. Letting it happen by sloth, which seems to be
the approach here, is counter to everything that Ada has been about.
****************************************************************
From: Tucker Taft
Sent: Thursday, September 10, 2020 7:30 PM
Fair enough. Perhaps:
"Any conformance requirements between aspect_specifications given on the
declaration and the completion of a subprogram are defined by the semantics
for any particular aspect."
****************************************************************
From: Steve Baird
Sent: Thursday, September 10, 2020 8:14 PM
I could support something like this as RM text that is marked as redundant.
It seems like there is an equal need (or lack of need) to say something
analogous about subtype conformance of profiles. If we are going to say
something about one, we should probably mention the other too.
****************************************************************
From: Tucker Taft
Sent: Thursday, September 10, 2020 8:32 PM
I presumed profile conformance is exactly what we are talking about when we
talk about conformance between a spec and a body of a subprogram.
We could make that crystal clear with:
"Any profile conformance requirements between aspect_specifications given on
the declaration and the completion of a subprogram are defined by the
semantics for any particular aspect."
****************************************************************
From: Randy Brukardt
Sent: Thursday, September 10, 2020 8:47 PM
Presumably something similar would be said about types as well? 6.3.1 already
includes conformance of discriminant parts, which are likely to get
aspect_specs (as proposed in AI12-0398-1).
****************************************************************
From: Randy Brukardt
Sent: Thursday, September 10, 2020 8:54 PM
I presume this is going into 6.3.1, so it seems pretty clear what conformance
requirements we are talking about. And the other conformance requirements are
already covered by normative wording, so I can't imagine why we'd want to
repeat anything about them in a user note.
I'd suggest going in the other direction and generalize it further:
NOTE: Any conformance requirements between aspect_specifications given on the
declaration and the completion of an entity are defined by the semantics for
any particular aspect. In particular, there is no general requirement to
repeat an aspect_specification on a completion.
As I noted in my previous message, we need to cover at least types with their
discriminant_part conformance. It doesn't hurt to mention (implicitly) other
matching between declarations and completions (even though this is going in a
place where conformance of profiles and discriminants is the primary topic).
****************************************************************
From: Randy Brukardt
Sent: Thursday, September 10, 2020 8:57 PM
BTW, I'd stick this either in AI12-0398-1 (justifable because of the
discriminant_part issue) or in the next presentation AI. I don't think
reopening or rejiggering AI12-0395-1 is needed.
****************************************************************
From: Jean-Pierre Rosen
Sent: Friday, September 11, 2020 1:39 AM
> I don't think that there is any other real case in Ada where some of
> the text of a profile is completely ignored when considering
> conformance rules. I think that deserves a user note at a minimum.
> Ignoring large blocks of text is completely against the philosophy of
> Ada; if we believe it makes sense we still need to explain ourselves.
> Letting it happen by sloth, which seems to be the approach here, is
> counter to everything that Ada has been about.
The simplest rule would be to apply to aspects the old Ada83 rule: the aspect
in the body must be the same suite of lexical elements as in the spec. Simple,
and would match what most users do: cut and paste.
****************************************************************
From: Steve Baird
Sent: Friday, September 11, 2020 2:08 PM
>> It seems like there is an equal need (or lack of need) to say
>> something analogous about subtype conformance of profiles. If we are
>> going to say something about one, we should probably mention the other too.
> I presumed profile conformance is exactly what we are talking about when we
>talk about conformance between a spec and a body of a subprogram.
>
> We could make that crystal clear with:
>
> "Any profile conformance requirements between aspect_specifications given on
> the declaration and the completion of a subprogram are defined by the
> semantics for any particular aspect."
When I said "subtype conformance" I was indirectly referring to
access-to-subprogram stuff (3.10.2(32/5), 4.6(24.20/3) and dispatching
operation stuff (3.9.2(10/2)).
My point is that this is about more than just spec/completion conformance
(i.e., more than just "full conformance").
****************************************************************
From: Tucker Taft
Sent: Friday, September 11, 2020 2:52 PM
Oh! I guess you were being too subtle for me...
Good point about access-to-subprogram. Anyone defining parameter aspects on
*specs* (as opposed to bodies) would need to worry about 'Access and
conversion between acc-to-subp types. And of course there is generic
matching, overriding of dispatching operations, etc.
The AdaCore use case, pragma Unreferenced --> aspect Unreferenced, is really
meant to be on a body (or expression function), so presumably has no
conformance requirements of any sort. But one could imagine something like
Convention on a parameter, where conformance would be required for acc-to-subp
conversions, overriding, etc.
Do you want to propose some (simple ;-) wording?
****************************************************************
From: Steve Baird
Sent: Friday, September 11, 2020 6:35 PM
> Do you want to propose some (simple;-) wording?
I like using the smile in the emoticon to close off the parenthesized
qualification, although it doesn't work so well if the emoticon is displayed
as something other than the three characters.
Perhaps an "Implementation Advice" section in 6.3.1 stating something like
An implementation's definition of any implementation-defined aspect
that may be specified for a formal parameter needs to include how
such aspect specifications interact with profile conformance.
Based on past experience, my chances of getting "which vs. that" right are
about 50/50.
****************************************************************
From: Randy Brukardt
Sent: Friday, September 11, 2020 7:23 PM
Implementation Advice doesn't seem right, as that implies documentation and
it's not clear that we want to add any additional documentation requirement
(as vacuous as those really are).
I had suggested a user note since it's users that I'm expecting to be
confused (it's unusual that there is no matching requirement on
aspect_specifications; I agree that we don't want one, but that should be
noted, not just glossed over). And I'd prefer the wording to cover
discriminant parts as well, as I think it is highly likely that we'll add
aspect_specifications to discriminant_specifications -- they are most
similar to components and parameters, both of which (now) allow
aspect_specifications.
Probably it would be best to concentrate on conformance in 6.3.1, so maybe a
user note something like:
NOTE: Any conformance requirements between aspect_specifications that are part
of a profile or known_discriminant_part are defined by the semantics of each
particular aspect. In particular, there is no general requirement for
aspect_specifications to match in conforming profiles or discriminant parts.
As far as the requirements for implementation-defined aspects, I already put
an AARM note next to the definition of formal parameters:
Discussion: Only implementation-defined aspects are allowed on formal
parameters in Ada 202x. Implementers are cautioned that any aspect allowed
on a formal parameter will need conformance rules. If, for instance, an
aspect changed the representation of a parameter, rules would be needed to
ensure that the representation is the same for the specification and body.
This could cover more if that makes sense, but I think there is already are
notes about similar sorts of stuff in 13.1.1. For instance, generic formal
matching of implementation-defined aspects is discussed in
AARM 13.1.1(18.b/5). Conformance is unique to formal_parameters (and
discriminant_specifications, should we go ahead with AI12-0398-1); there
aren't any other things that have aspect specifications can be used in
profiles.
If we wanted to say more about what implementers need to be aware of, that
would make most sense as notes after 13.1.1(38/3) -- the permission for
implementations to support impldef aspects.
****************************************************************
From: Tucker Taft
Sent: Friday, September 11, 2020 7:31 PM
I am fine with what you proposed, Randy. I don't see a need to go overboard
here...
****************************************************************
From: Jean Pierre-Rosen
Sent: Wednesday, October 21, 2020 12:06 PM
I noticed during the meeting that the AI said:
!ASIS
[Not sure. It seems like some new capabilities might be needed, but I didn't
check - Editor.]
The official ASIS standard has not been updated since Ada95, therefore it does
not address aspects at all. Assuming that an evolution of ASIS would simply
bless what ASIS-for-Gnat does, the current Aspect related query expects any
declaration. So no new capability (beyond the general aspect query) would be
needed.
****************************************************************
From: Randy Brukardt
Sent: Thursday, October 22, 2020 6:30 PM
> !ASIS
>
> [Not sure. It seems like some new capabilities might be
> needed, but I didn't check - Editor.]
FYI, that's the default text found in the templates I use for creating AIs.
If I fail or forget to change it, that's what an AI (any AI) will say. I tend
only to change AIs where it is completely obvious.
> The official ASIS standard has not been updated since Ada95,
> therefore it does not address aspects at all. Assuming that
> an evolution of ASIS would simply bless what ASIS-for-Gnat
> does, the current Aspect related query expects any
> declaration. So no new capability (beyond the general aspect
> query) would be needed.
Good to know. I changed the AI accordingly.
****************************************************************
Questions? Ask the ACAA Technical Agent