!standard 6.1(15/3) 20-09-03 AI12-0395-1/01 !class Amendment 20-09-03 !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. !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. ****************************************************************