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

Differences between 1.11 and version 1.12
Log of other versions for file ai12s/ai12-0020-1.txt

--- ai12s/ai12-0020-1.txt	2018/06/16 02:14:33	1.11
+++ ai12s/ai12-0020-1.txt	2018/07/06 05:25:13	1.12
@@ -3079,3 +3079,224 @@
 pain we have to repeat the better.
 
 ***************************************************************
+
+From: Steve Baird
+Sent: Monday, June 18, 2018  6:39 PM
+
+>> I agree that we should be consistent with the treatment of the 
+>> stream-oriented attributes here. Would it be worth trying to factor 
+>> this out in order to avoid duplication? Perhaps a general 13.1.1 rule 
+>> that, unless otherwise specified for a particular aspect, the 
+>> subprogram named in an aspect specification for a subprogram-valued 
+>> aspect shall not be abstract? Then we'd have to go find and remove 
+>> all the existing wording that would become redundant as a result of 
+>> this change.
+> 
+> It might make sense (not that I'm volunteering). The existing rule 
+> like that is 13.3(6), so I would think it would make the most sense to extend that.
+> Alternatively, we might want to move that existing rule into 13.1 
+> (since it should apply regardless of the syntax of specification), and then extend it.
+> That would eliminate one more use of the blanket equivalence rule -- 
+> the fewer uses of that, the better.
+
+Agreed. Even if we don't clean up the equivalence stuff at this point, let's 
+not make it worse.
+
+So suppose we add the following new paragraph in 13.1.1 immediately after 
+18.1/4 (i.e., just before getting into the "nonoverridable"
+rules):
+
+   Unless otherwise specified for a particular aspect, the subprogram
+   named in an aspect_specification, an attribute_definition_clause
+   or a pragma which specifies a subprogram-valued aspect shall not be
+   abstract.
+
+   Unless otherwise specified for a particular aspect,
+   if a subprogram-valued aspect is specified for an interface type,
+   the subprogram name given in the aspect_specification,
+   attribute_definition_clause, or pragma shall statically denote a null
+   procedure. This rule does not apply to the four class-wide
+   stream-oriented attributes [(i.e., Read'Class, Write'Class,
+   Input'Class, and Ouput'Class)].
+
+In addition to the new Put_Image aspect that is introduced in this AI, I think
+this rule would also apply to the following already-defined aspects:
+
+    1) Read/Write/Input/Ouput['Class]
+    2) Stable_Properties['Class]
+    3) Constant_Indexing/Variable_Indexing
+    4) Default_Iterator
+
+I could easily have missed some; for example, if you look for aspect 
+definitions in K.1 which mention "subprogram", "function", "procedure" or
+"entry", you will not find Default_Iterator.
+
+So I went looking for existing wording that ought to be removed because the 
+proposed change would render it redundant.
+
+1) Of course there is the streaming rule that started this whole
+    business, 13.13.2(38.1/4). That paragraph would need to be removed.
+
+2) For Stable_Properties, I didn't find any such rule (which seems like
+    an oversight in the Stable_Properties definition). We probably also
+    don't want to allow specifying Stable_Properties (as opposed to
+    Stable_Properties'Class) for an abstract type, but that's a separate
+    question.
+
+3) For Constant_Indexing/Variable_Indexing, I also don't think any
+    wording change is needed (and, with #2, I think this new wording
+    plugs some holes).
+
+    This case is (sort of) handled by the existing 4.1.6 rule
+      A generalized_indexing is illegal if the equivalent prefixed view
+      (see below) is illegal.
+    which will catch the case of a non-dispatching call to an abstract
+    subprogram. But that wording doesn't help catch anything at the
+    point of the aspect specification (and specifying an abstract
+    subprogram for a nonoverridable aspect doesn't seem like something
+    we want to allow).
+
+4) Same situation as #3, including the fact that this is another
+    nonoverridable aspect. The situation is actually worse because we
+    don't have anything analogous to the "is illegal if the equivalent
+     ... is illegal" rule that we have in #3.
+
+So in summary, it looks like this new wording plugs some holes in
+3 out of 4 cases and the only wording that would need to be removed is 
+13.13.2(38.1/4).
+
+As always, any review is welcome.
+
+And yes, I know this is way past the deadline.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 19, 2018  4:27 PM
+
+You are very confused about Stable_Properties. It takes a "list of functions"
+(or, if the new AI is approved, "an aggregate of function names"), not a 
+"function", so regardless of whatever wording you are writing, it does not
+apply to Stable_Properties. Whether Stable_Properties needs an abstract rule
+of it's own is a separate question (it might not, since the name is required 
+to be a "property function", and I don't recall the rules that needs right 
+now. (I'm too tired to look, answering mail and going to bed...Jet Lag does 
+that to one.) I don't think it needs to be tied into the null procedure rule,
+since again it has to be a property *function*.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 29, 2018  7:43 PM
+
+I answered this one originally when I was jet lagged right after arriving in 
+Lisbon. Let me finish the thought...
+
+...
+> So suppose we add the following new paragraph in 13.1.1 immediately 
+> after 18.1/4 (i.e., just before getting into the "nonoverridable" 
+> rules):
+> 
+>    Unless otherwise specified for a particular aspect, the subprogram
+>    named in an aspect_specification, an attribute_definition_clause
+>    or a pragma which specifies a subprogram-valued aspect shall not be
+>    abstract.
+> 
+>    Unless otherwise specified for a particular aspect,
+>    if a subprogram-valued aspect is specified for an interface type,
+>    the subprogram name given in the aspect_specification,
+>    attribute_definition_clause, or pragma shall statically denote a null
+>    procedure. This rule does not apply to the four class-wide
+>    stream-oriented attributes [(i.e., Read'Class, Write'Class,
+>    Input'Class, and Ouput'Class)].
+
+Generally, rules that apply to all kinds of aspects belong in 13.1; 13.1.1 is 
+about rules that only apply to aspect_specifications. Otherwise, this looks 
+fine to me.
+
+> In addition to the new Put_Image aspect that is introduced in this AI, 
+> I think this rule would also apply to the following already-defined 
+> aspects:
+> 
+>     1) Read/Write/Input/Ouput['Class]
+>     2) Stable_Properties['Class]
+>     3) Constant_Indexing/Variable_Indexing
+>     4) Default_Iterator
+> 
+> I could easily have missed some; for example, if you look for aspect 
+> definitions in K.1 which mention "subprogram", "function", "procedure" 
+> or "entry", you will not find Default_Iterator.
+> 
+> So I went looking for existing wording that ought to be removed 
+> because the proposed change would render it redundant.
+> 
+> 1) Of course there is the streaming rule that started this whole
+>     business, 13.13.2(38.1/4). That paragraph would need to be removed.
+> 
+> 2) For Stable_Properties, I didn't find any such rule (which seems like
+>     an oversight in the Stable_Properties definition). We probably also
+>     don't want to allow specifying Stable_Properties (as opposed to
+>     Stable_Properties'Class) for an abstract type, but that's a separate
+>     question.
+
+I partially previously answered this one. But we do need a rule that disallows 
+abstract functions for Stable_Properties (it seems OK for 
+Stable_Properties'Class), and also abstract types for Stable_Properties.
+
+So:
+
+Add before 7.3.4(10/5):
+
+"The aspect Stable_Properties shall not be specified for an abstract type."
+
+AARM Ramification: The above rule does not apply to Stable_Properties'Class 
+aspects.
+
+Add after 7.3.4(13/5):
+
+"Furthermore, a stable property function used in a Stable_Properties aspect 
+shall not be abstract."
+
+AARM Ramification: The above rule does not apply in Stable_Properties'Class 
+aspects.
+
+> 3) For Constant_Indexing/Variable_Indexing, I also don't think any
+>     wording change is needed (and, with #2, I think this new wording
+>     plugs some holes).
+> 
+>     This case is (sort of) handled by the existing 4.1.6 rule
+>       A generalized_indexing is illegal if the equivalent prefixed view
+>       (see below) is illegal.
+>     which will catch the case of a non-dispatching call to an abstract
+>     subprogram. But that wording doesn't help catch anything at the
+>     point of the aspect specification (and specifying an abstract
+>     subprogram for a nonoverridable aspect doesn't seem like something
+>     we want to allow).
+
+Right. The new rule seems like an improvement; if no possible call would be 
+legal, why allow the aspect specification?
+
+> 4) Same situation as #3, including the fact that this is another
+>     nonoverridable aspect. The situation is actually worse because we
+>     don't have anything analogous to the "is illegal if the equivalent
+>      ... is illegal" rule that we have in #3.
+
+We have 5.5.2(6.2/4), which makes the iterator illegal if the Default Iterator 
+function call is illegal; so there is no hole. (There *was* a reason for this 
+generically defined rule; it was originally added to catch constant containers
+when the parameter is "in out").
+
+Again, the new rule seems like an improvement, but it's not strictly 
+necessary.
+
+> So in summary, it looks like this new wording plugs some holes in
+> 3 out of 4 cases and the only wording that would need to be removed is 
+> 13.13.2(38.1/4).
+> 
+> As always, any review is welcome.
+> 
+> And yes, I know this is way past the deadline.
+
+I was too tired to complain. ;-)
+
+**************************************************************

Questions? Ask the ACAA Technical Agent