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

Unformatted version of ai12s/ai12-0398-1.txt version 1.3
Other versions for file 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, enumeration literals, 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 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. 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).
!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