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

--- ai12s/ai12-0005-1.txt	2017/06/06 01:45:44	1.22
+++ ai12s/ai12-0005-1.txt	2017/08/12 02:48:59	1.23
@@ -1008,7 +1008,189 @@
 
 ***************************************************************
 
-Editor's note (June 5, 2017): All of the items above this
+[Editor's note: The following is a heavily edited part of a private thread 
+not related to the Ada Standard.]
+
+From: Gary Dismukes
+Sent: Tuesday, August 8, 2017  7:29 PM
+
+Consider:
+
+   package Aspects is
+      X : constant Integer;
+
+      type A is new Natural with Size => X;
+
+   private
+      X : constant Integer := Integer'Size;
+   end Aspects;
+
+One might think that the expression for aspect Size should be static, though
+clearly "X" is not a static expression here, since it refers to a deferred
+constant.  If it's required to be static, then it's illegal, but there seem
+to be no rules that require the expression of the aspect to be static (though
+if it were to be given in an attribute_definition_clause for Size it would
+have to be static, by 13.3(48)), which is more than a bit surprising to us.
+Our expectation is that specifying the Size as an aspect would be subject to
+the same static restriction as the attribute clause.  (If for some reason
+X *is* considered static here, then this would be illegal, as a consequence
+of 13.14(7.2/3).)
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, August 8, 2017  8:47 PM
+
+13.3(48) applies to aspect specifications via the equivalence rule of
+13.1.1(31/3). If that wasn't true, we'd have to repeat all of the Legality
+Rules and details for specifying each attribute when specifying as an aspect,
+which would completely defeat the purpose of this equivalence. The Dewar rule
+at a minimum says that all of 13.3 applies to the similar aspects.
+
+Perhaps it would be good to add an AARM note, or even a bit of wording, to this
+equivalence to make it clear that all of the rules for attribute specification
+apply to aspect specification. But the entire intent would be broken if this
+was not the case.
+
+***************************************************************
+
+From: Steve Baird
+Sent: Wednesday, August 9, 2017  2:22 PM
+
+> Perhaps it would be good to add an AARM note, or even a bit of 
+> wording, to this equivalence to make it clear that all of the rules 
+> for attribute specification apply to aspect specification. But the 
+> entire intent would be broken if this was not the case.
+
+Agreed on both points.
+I think clarification is needed here.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, August 9, 2017  11:09 PM
+
+I'm leaning toward an AARM Note, because I can add those without getting a
+full ARG discussion involved. I don't want to rewrite all of 13.3 and parts
+of 13.11 and other clauses. (Likely to introduce a lot of bugs.)
+
+The note would say something like:
+
+AARM Ramification: Unless specified otherwise, all of the requirements on
+specifying a specific aspect with an attribute_definition_clause also apply
+to the an aspect_specification for the aspect. For instance, for the Size
+aspect for the subtype, the expression has to be a static expression with
+an integer type and nonnegative value, all of the recommended level of
+support requirements apply if Annex C is supported, and so on.
+
+OK? If not, I'll trust that you'll take the question to the ARG list. (I
+don't want to cause the "wrath of Bob", especially as this equivalence
+semantics was his idea.)
+
+***************************************************************
+
+From: Steve Baird
+Sent: Thursday, August 10, 2017  11:13 AM
+
+> AARM Ramification: Unless specified otherwise, all of the requirements 
+> on specifying a specific aspect with an attribute_definition_clause 
+> also apply to the an aspect_specification for the aspect. For 
+> instance, for the Size aspect for the subtype, the expression has to 
+> be a static expression with an integer type and nonnegative value, all 
+> of the recommended level of support requirements apply if Annex C is
+> supported, and so on.
+
+Looks good, and I agree that adding AARM wording is the right thing to do
+here.
+
+Some minor wordsmithing:
+
+   AARM Ramification: Unless specified otherwise, all of the requirements
+   [for] {on} specifying a specific aspect with an
+   attribute_definition_clause also apply
+   to [an] {the} aspect_specification for the aspect. For instance, when
+   [specifying] the  Size aspect [of a] {for the} subtype, the expression
+   has to be a static expression with an integer type and [a] nonnegative
+   value, all of the recommended level of support requirements apply if
+   Annex C is supported, and so on.
+
+I'd also consider using "particular" instead of "specific" just because we
+are already talking about specifications. Ditto for "example" instead of
+"instance" just because somebody searching the RM for "instance" probably
+doesn't want to see this.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, August 10, 2017  9:54 PM
+
+...
+> Looks good, and I agree that adding AARM wording is the right thing to 
+> do here.
+
+Thanks, and good.
+
+> Some minor wordsmithing:
+> 
+>    AARM Ramification: Unless specified otherwise, all of the requirements
+>    [for] {on} specifying a specific aspect with an
+>    attribute_definition_clause also apply
+>    to [an] {the} aspect_specification for the aspect. For instance, when
+>    [specifying] the  Size aspect [of a] {for the} subtype, the expression
+>    has to be a static expression with an integer type and [a] nonnegative
+>    value, all of the recommended level of support requirements apply if
+>    Annex C is supported, and so on.
+
+You confused the heck out of me by getting the insertions and deletions
+backwards. I couldn't figure out why you were deleting the better version in
+most of the text. Finally, I went carefully back to the original and figured
+out the problem.
+
+> I'd also consider using "particular" instead of "specific" 
+> just because we are already talking about specifications. 
+> Ditto for "example"
+> instead of "instance" just because somebody searching the RM for 
+> "instance" probably doesn't want to see this.
+
+Makes sense.
+
+I added a sentence about these rules being enforced at the freezing point (like
+all other aspect rules), after rereading Gary's original question. I wanted it
+to be clear that A is legal below:
+
+   package Aspect2 is
+      X : constant Integer;
+   private
+      type A is new Natural with Size => X; -- OK, does not freeze X.
+      type B is new Natural with Size => X;
+      Obj : B; -- Illegal, freezes B and X, and X is not completed yet.
+      X : constant Integer := Integer'Size;
+   end Aspect2; -- A frozen here.
+
+The whole thing would be legal if Obj was removed; when A is frozen, X is
+resolved to a static constant.
+
+Anyway, I've added the following to the draft AARM. Coincidentally, that
+should be posted with the minutes tomorrow -- talk about service! :-)
+
+    AARM Ramification: Unless specified otherwise, all of the requirements
+    for specifying a particular aspect with an attribute_definition_clause also
+    apply to an aspect_specification for the aspect. These are enforced at the
+    freezing point of the entity. For example, when
+    specifying the Size aspect of a subtype, the expression
+    has to be a static expression with an integer type and a nonnegative
+    value, all of the recommended level of support requirements apply if
+    Annex C is supported, and so on.
+
+            Randy.
+
+P.S. You could argue that this is a To Be Honest note rather than a
+Ramification, but that's the sort of useless argument that I'd prefer
+to avoid.
+
+***************************************************************
+
+Editor's note (August 10, 2017): All of the items above this
 marker have been included in the working version of the AARM.
 
 ****************************************************************