Version 1.6 of ai12s/ai12-0395-1.txt

Unformatted version of ai12s/ai12-0395-1.txt version 1.6
Other versions for file ai12s/ai12-0395-1.txt

!standard 6.1(15/3)          20-09-03 AI12-0395-1/01
!class Amendment 20-09-03
!status Amendment 1-2012 20-09-10
!status WG9 Approved 22-06-22
!status ARG Approved 12-0-2 20-09-09
!status work item 20-09-03
!status received 20-09-02
!priority Low
!difficulty Easy
!subject Allow aspect_specifications on formal parameters
!summary
Ada syntax is modified so that a parameter_specification includes an optional aspect_specification. It remains the case that no language-defined aspects can be specified for a formal parameter using this new syntax, but with this change an implementation might choose to define a new aspect which could be specified in this way.
!problem
It would be useful to be able to specify implementation-defined aspects for formal parameters, but Ada syntax currently does not allow this.
One use case for this is an implementation-defined Unreferenced aspect, used to indicate that a parameter is deliberately unreferenced. This is just one of several possible cases where this capability could be useful.
!wording
Replace 6.1(15/3)
parameter_specification ::= defining_identifier_list : [aliased] mode [null_exclusion] subtype_mark [:= default_expression] | defining_identifier_list : access_definition [:= default_expression]
with
parameter_specification ::= defining_identifier_list : [aliased] mode [null_exclusion] subtype_mark [:= default_expression] [aspect_specification] | defining_identifier_list : access_definition [:= default_expression] [aspect_specification]
In 13.1.1(4.b/5) replace
parameter_specification -- NO
with
parameter_specification* -- There are no language-defined aspects that may be specifed -- on parameter specifications, but implementations might support some.
!discussion
This proposed change does not require any changes for Ada compilers; it only grants implementations the option of allowing specification of implementation-defined aspects as part of a parameter_specification.
It happens that there is particular interest in use of this construct with expression functions. For example, this would allow (but not require) an implementation to support something like
function Foo (X : Natural; Y : Natural with Unreferenced) return Natural is (2 * X);
where the aspect specification indicates that the parameter Y is deliberately unreferenced.
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).
It is believed that the present RM wording would disallow the specification of any language-defined aspect using this new syntax. For example, C.6 introduces the Atomic, Independent, and Volatile aspects with
"For an object_declaration, a component_declaration, a full_type_declaration, or a formal_complete_type_declaration, the following representation aspects may be specified:".
If there is some case where the present RM wording would allow the use of this new syntax to specify a language-defined aspect, then this is an oversight that should be corrected. Do we want to say something to this effect in, for example, an AARM note in 13.13 ?
One could imagine using an alternative syntax something like
procedure Foo (X with Some_Aspect, Y, Z : T) is ... ;
to allow specifying aspects for individual members of a factored list of parameters, but this seems like a bad idea. See the discussion of AI12-0285 and think of examples like
procedure Foo (Param_1 with Aspect_1, Aspect_2, Param_2, Param_3 : T);
One could imagine similarly extending the syntax of other forms of declarations (see the list in AARM 13.1.1(4.b)). There currently appears to be no interest in this.
One could imagine restricting this permission so that it does not apply in the access parameter case (the case where the parameter_specification includes an access_definition). There seems to be no clear reason for doing this, but it seemed worth mentioning in case there is some interesting interaction here between access specifications and anonymous access types.
Tuck outlined a different approach that seems worth mentioning. Instead of making specific changes to the syntax, we could instead provide a blanket permission for implementations to add aspect_specifications where they see fit. If we couple this with the ability to ignore aspect specifications that are unrecognized, these effectively become even more like pragmas.
!corrigendum 6.1(15/3)
Replace the paragraph:
parameter_specification ::= 
    defining_identifier_list : [aliasedmode [null_exclusionsubtype_mark [:= default_expression]
  | defining_identifier_list : access_definition [:= default_expression]
by:
parameter_specification ::= 
    defining_identifier_list : [aliasedmode [null_exclusionsubtype_mark [:= default_expression]
        [aspect_specification]
  | defining_identifier_list : access_definition [:= default_expression]
        [aspect_specification]
!ASIS
No effect on the defined subprograms. The routine for extracting aspect specification would have to allow being passed a parameter rather than other kinds of declaration.
!ACATS test
Only implementation=defined aspects are allowed, so there is nothing usefully testable.
!appendix

From: Steve Baird
Sent: Wednesday, September 2, 2020  1:32 PM

This is a new AI. [This is version /01 of the AI - Editor.]

Thanks to Tuck and Randy for preliminary review.

****************************************************************

From: Randy Brukardt
Sent: Thursday, September 3, 2020  8:49 PM

> Tuck outlined a different approach that seems worth mentioning.
> Instead of making specific changes to the syntax, we could instead 
> provide a blanket permission for implementations to add 
> aspect_specifications where they see fit. If we couple this with the 
> ability to ignore aspect specifications that are unrecognized, these 
> effectively become even more like pragmas.

Even pragmas have restrictions on where they can be placed. Attempting to 
develop those for aspect_specifications sounds like a significant amount of 
work, and not having any could led to different implementations putting 
aspect_specifications in different places on the same construct.

Since we already have aspect_specifications on almost every kind of 
declaration and body, it would almost certainly be easier to just add them 
to the syntax of the remaining declarations. It makes sense to consider this,
since we've come up with plausible uses for many of the remaining cases. 
(Based on the list in AARM 13.1.1.) Otherwise, we're going to be doing AIs 
like this every few months until we have added nearly everything.

I discussed this a bit with Tucker and Steve:

 * parameter_specification: the subject of this AI.

 * extended_return_statement: declares an object with all of the usual 
   properties; it seems reasonable that someone might want to use an aspect 
   specification to set some property.

 * enumeration_literal_specification: we already have a request on Ada-Comment 
   to allow specifying representation with the literal declaration. It seems 
   reasonable to allow implementations to experiment with allowing this via 
   some aspect_specification. Note that we allow similar specifications on 
   component declarations, and we're proposing to do so here for 
   parameter_specifications, so we're already allowing aspect specifications 
   in the middle of larger declarations.

 * incomplete_type_declaration: It's unclear if this would be a good idea. We 
   don't allow reading (via attributes) most aspects. Moreover, it's pretty 
   likely that the majority of the existing wording for aspect definitions 
   assumes that incomplete types aren't relevant, so we'd have to look at a 
   lot of wording if we were to allow this syntactically (either to ensure 
   that it is not allowed or to define an appropriate restriction on 
   completions). Certainly too late this time.

 * number_declaration: Another unclear situation. We generally assume these 
   are pure values with no other properties; usually they can be used 
   anywhere that a value can. Allowing contracts on them might cause issues 
   (of course no implementation would be required to do anything as nothing 
   language-defined would be involved). We'd need to check all of the object 
   aspects to ensure the wording didn't allow them on number decls. I'd rather
   not do anything for these now in order to avoid trouble.

 * loop_parameter_specification, iterated_component_association, 
   iterated_parameter_specification, choice_parameter_specification: These are 
   all part of some larger construct, the aspect_specification would usually 
   be better on the larger construct. They're all implicitly declared as well, 
   and it's unclear that we would want to be specifying properties of them (as 
   opposed to the larger construct). For parallel loops, we already have 
   proposed aspect specifications be allowed as part of the parallel 
   declaration. As such, I don't think we want to allow them on the loop 
   parameter as well, which could be confusing (before or after "I" would have 
   a rather different meaning).

---------

So I'd propose that we'd also change as part of this AI 3.5.1(3):

   enumeration_literal_specification ::=  
     defining_identifier [aspect_specification] |
     defining_character_literal [aspect_specification] 

and 6.5(2.1/4):

extended_return_object_declaration ::= 
    defining_identifier : [aliased][constant] return_subtype_indication [:= expression] [aspect_specification]

with associated changes to AARM 13.1.1(4.b/5) (changing "No" to "*").

****************************************************************

From: Gary Dismukes
Sent: Thursday, September 3, 2020  9:03 PM

What about discriminant_specifications?  Those are similar to formals.

****************************************************************

From: Randy Brukardt
Sent: Thursday, September 3, 2020  11:02 PM

Somehow missed those on 3 different passes through the 13.1.1(4.b/5) list 
on two different days.

It seems that discriminant_specifications should be included, given that 
formal parameters and components both allow aspect_specifications. Ergo, 
add 3.7(5/2):

discriminant_specification ::= 
    defining_identifier_list : [null_exclusion] subtype_mark [:= default_expression] [aspect_specification]
  | defining_identifier_list : access_definition [:= default_expression] [aspect_specification]

to the list above.

****************************************************************

Questions? Ask the ACAA Technical Agent