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

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

--- ai12s/ai12-0020-1.txt	2018/06/15 02:05:26	1.10
+++ ai12s/ai12-0020-1.txt	2018/06/16 02:14:33	1.11
@@ -3007,3 +3007,75 @@
 6 AIs - streams were a mess years ago!)
 
 ***************************************************************
+
+From: Steve Baird
+Sent: Friday, June 15, 2018  7:34 PM
+
+Good catches.
+
+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 wouldn't bother me to outlaw specifying Put_Image for an interface type, 
+except that I agree that we want to be consistent with the streaming stuff. So
+I agree with your suggestion that we impose a "must be a null procedure" rule.
+
+***************************************************************
+
+From: Steve Baird
+Sent: Friday, June 15, 2018  7:41 PM
+
+> It wouldn't bother me to outlaw specifying Put_Image for an interface 
+> type
+
+I take it back; that would cause contract problems for generics with formal 
+types where the corresponding actual might or might not be an interface type.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 15, 2018  7:54 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.
+
+I.e.
+
+For the specification of an aspect that denotes a subprogram, the subprogram 
+shall not be abstract, the profile shall be mode conformant with the one 
+required for the aspect, and the convention shall be Ada. Additional 
+requirements are defined for particular aspects. 
+
+OTOH, the blanket rule doesn't work in reverse (aspect rules don't 
+automatically apply to attribute_definition_clauses), so it's unclear that 
+would work as written above. I'd have to look at how 13.1 works to get this 
+wording right - I'll leave that to you (along with finding any wording that is
+unneeded after adding this).
+
+> It wouldn't bother me to outlaw specifying Put_Image for an interface 
+> type, except that I agree that we want to be consistent with the 
+> streaming stuff. So I agree with your suggestion that we impose a 
+> "must be a null procedure" rule .
+
+Yeah, it took a long time to get the rules for streams right, the less of that
+pain we have to repeat the better.
+
+***************************************************************

Questions? Ask the ACAA Technical Agent