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

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0398-1.txt

--- ai12s/ai12-0398-1.txt	2020/10/15 04:47:50	1.2
+++ ai12s/ai12-0398-1.txt	2020/10/22 23:58:59	1.3
@@ -1,14 +1,15 @@
-!standard 3.5.1(3)                                  20-10-14  AI12-0398-1/02
-!standard 3.7(5/2)
+!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 have aspect specifications
+!subject Most declarations should allow aspect specifications
 !summary
 
 Aspect_Specifications are added to extended return object declarations, 
@@ -24,11 +25,11 @@
 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, 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 a directly enclosing entity does not provide an
-preferred alternative.
+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 a directly enclosing entity does not 
+provide a preferred alternative.
 
 !proposal
 
@@ -36,12 +37,6 @@
 
 !wording
 
-Replace 3.5.1(3) with:
-
-enumeration_literal_specification ::=
-    defining_identifier [aspect_specification]
-  | defining_character_literal [aspect_specification]
-
 Replace 3.7(5/2) with:
 
 discriminant_specification ::= 
@@ -80,7 +75,7 @@
 incomplete_type_declaration - NO:
 
 According to AI12-0396-1, these do not even have aspects, and Legality Rules
-have long preventing reading aspects of an incomplete view via an attribute 
+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).
 
@@ -91,28 +86,12 @@
 
 discriminant_specification - YES:
 
-Similar declarations component_declarations and formal_parameters both allow 
+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.
 
-enumeration_literal_specification - YES:
-
-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.
-While this is a need that will not be directly addressed in Ada 202x,
-providing an avenue for implementers to address this if their customers demand
-it seems valuable. And that 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);
-
 entry_index_specification - YES:
 
 This serves a similar purpose to a parameter of a protected entry. However, it
@@ -136,12 +115,40 @@
 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 unambigiously be used for any aspect that needs
+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
@@ -151,7 +158,7 @@
 
 iterated_component_association - NO:
 
-This is specifically the loop parameter of traditional form of the array 
+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
@@ -207,33 +214,30 @@
 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(?):
+choice_parameter_specification - NO:
 
-This appears in the list of an exception_handler. The author thinks that 
-allowing an aspect_specification would cause confusing syntax as it would
+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 => ...;
 
-There's no known plausible use for an aspect specification here, as well,
+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.
-
-[Author's note: I'm not that sure about this one. Better arguments (either way)
-welcome.]
+necessary on choice parameters (if you don't need the name, just omit it 
+completely).
 
 !ASIS
 
-[Not sure. It seems like some new capabilities might be needed,
-but I didn't check - Editor.]
+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 implementation-defined
+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 low value.
+that seems to be very low value.
 
 !appendix
 
@@ -551,5 +555,46 @@
 
 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.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent