CVS difference for ai12s/ai12-0398-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file 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