!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) @drepl @xindent<@fa@fa<@ ::=@ >@hr @ @ @ @fa@ :@ [@fa]@ @fa@ [:=@ @fa]@hr @ |@ @fa@ :@ @fa@ [:=@ @fa]> @dby @xindent<@fa@fa<@ ::=@ >@hr @ @ @ @fa@ :@ [@fa]@ @fa@ [:=@ @fa]@ [@fa]@hr @ |@ @fa@ :@ @fa@ [:=@ @fa]@ [@fa]> !corrigendum 6.3.1(25) @dinsa An implementation may declare an operator declared in a language-defined library unit to be intrinsic. @dinst @xindent<@s9s that are part of a profile or @fa are defined by the semantics of each particular aspect. In particular, there is no general requirement for @fas to match in conforming profiles or discriminant parts.>> !corrigendum 6.5(2.1/3) @drepl @xindent<@fa@fa<@ ::=@ >@hr @ @ @ @ @fa@ :@ [@b][@b]@ @fa@ [:=@ @fa]> @dby @xindent<@fa@fa<@ ::=@ >@hr @ @ @ @ @fa@ :@ [@b][@b]@ @fa@ [:=@ @fa]@ [@fa]> !corrigendum 9.5.2(8) @drepl @xindent<@fa@fa<@ ::=@ >@b@ @fa@ @b@ @fa> @dby @xindent<@fa@fa<@ ::=@ >@b@ @fa@ @b@ @fa@ [@fa]> !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. ****************************************************************