CVS difference for ai12s/ai12-0398-1.txt
--- ai12s/ai12-0398-1.txt 2020/09/11 22:27:23 1.1
+++ ai12s/ai12-0398-1.txt 2020/10/15 04:47:50 1.2
@@ -1,6 +1,8 @@
-!standard 3.5.1(3) 20-09-10 AI12-0398-1/01
+!standard 3.5.1(3) 20-10-14 AI12-0398-1/02
!standard 3.7(5/2)
+!standard 6.3.1(25)
!standard 6.5(2.1/3)
+!standard 9.5.2(8)
!class Amendment 20-09-10
!status work item 20-09-10
!status received 20-09-09
@@ -10,7 +12,8 @@
!summary
Aspect_Specifications are added to extended return object declarations,
-discriminant specifications, and enumeration literals.
+discriminant specifications, enumeration literals, and entry index
+specifications.
!problem
@@ -45,11 +48,29 @@
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
@@ -74,7 +95,7 @@
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 both discriminants as well as regular components.
+need to work on discriminants as well as regular components.
enumeration_literal_specification - YES:
@@ -92,6 +113,18 @@
Blue with Rep => 4,
White with Rep => 7);
+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
@@ -184,24 +217,12 @@
There's no known plausible use for an aspect specification here, as well,
given that the entity is naming something provided by the implementation that
-cannot be changed.
+cannot be changed. Additionally, the name is optional, so Unreferenced is not
+necessary on choice parameters.
[Author's note: I'm not that sure about this one. Better arguments (either way)
welcome.]
-entry_index_specification - NO(?):
-
-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. There doesn't seem to be any use for that.
-
-[Author's note: The conclusion here is reverse that of extended returns, which
-have similar limitations. Assuming that aspect specs don't participate in
-conformance, there wouldn't be a problem allowing one here. I'm on the
-fence, additional opinions welcome.]
-
!ASIS
[Not sure. It seems like some new capabilities might be needed,
@@ -239,3 +260,296 @@
****************************************************************
+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...
+
+****************************************************************
Questions? Ask the ACAA Technical Agent