Version 1.6 of 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 : [aliased] mode [null_exclusion] subtype_mark [:= default_expression]
| defining_identifier_list : access_definition [:= default_expression]
by:
parameter_specification ::=
defining_identifier_list : [aliased] mode [null_exclusion] subtype_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