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

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

--- ai12s/ai12-0106-1.txt	2014/05/14 23:19:04	1.1
+++ ai12s/ai12-0106-1.txt	2014/08/12 00:58:45	1.2
@@ -1,4 +1,4 @@
-!standard 13.13.2(38/3)                                14-05-14  AI05-0106-1/01
+!standard 13.13.2(38/3)                                14-08-11  AI05-0106-1/02
 !class binding interpretation 14-05-14
 !status work item 14-05-14
 !status received 14-04-25
@@ -37,25 +37,24 @@
 
 !wording
 
+[Editor's note: The below wording assumes that the changes of AI12-0106-1
+are adopted. Note that 13.13.2(38/3) is split into two paragraphs, and
+we only modify the first.]
+
+[IMPORTANT: I've only split the AI as directed; I made no attempt to
+"rationalize" the AI as Tucker volunteered to do. That may change the wording
+and certainly will change the discussion.]
+
 Modify 13.13.2(38/3):
 
 The stream-oriented attributes may be specified for any type via an
-attribute_definition_clause. {Redundant[Alternatively, each of the specific
+attribute_definition_clause. Redundant[Alternatively, each of the specific
 stream attributes can be specified using an aspect_specification on any
 type_declaration, with the aspect name being the corresponding attribute
-name.] Each of the class-wide stream attributes can be specified for a tagged
+name.]{ Each of the class-wide stream attributes can be specified for a tagged
 type T using the name of the stream attribute followed by 'Class; such
 class-wide aspects are not inherited for other descendants of T.}
 
-[Editor's note: The redundant sentence above is added simply so that we don't
-just talk about specifying class-wide stream attributes with an
-aspect_specification. That would make it appear as though the specific stream
-attributes cannot be specified that way, even though the blanket rule
-13.1.1(31/3) says that they can.]
-
-AARM Proof: 13.1.1 says that all operational attributes that can be specified
-with an aspect_specification.
-
 AARM Reason: We need the last sentence to override the blanket rule given in
 13.1.1 that aspect'Class applies to the type and all descendants.
 
@@ -64,21 +63,6 @@
 above paragraph, the other existing AARM notes will follow the split paragraph
 below.]
 
-The subprogram name given in such [a clause]{an attribute_definition_clause
-or aspect_specification} shall statically denote a subprogram that is not an
-abstract subprogram. Furthermore, if a stream-oriented attribute is specified
-for an interface type [by an attribute_definition_clause}, the subprogram name
-given in the {attribute_definition_clause or aspect_specification}[clause]
-shall statically denote a null procedure.
-
-[Editor's note: I'm dubious that the latter rule should apply to class-wide
-attributes/aspects. The point is to prevent specifying non-dispatching routines
-for interfaces, but of course the class-wide routines will have dispatching
-contents. So they pose no problem. As that would be a change, I didn't change
-the wording to that effect, but perhaps we should? I don't think we thought
-about the class-wide attributes when we adopted the rule. Just adding the word
-"specific" should do the trick, I think.]
-
 !discussion
 
 We want to be able to use aspect_specifications in as many cases as possible,
@@ -87,8 +71,7 @@
 such names is <aspect>'Class. So we add an appropriate definition so that there
 can be no doubt about the intent.
 
-Of course, we want this for all four stream attributes, so we have wording for
-each aspect.
+Of course, we want this for all four stream attributes.
 
 Note that 13.1.1(29/3) says that a class-wide aspect of a type applies to all
 descendants of the type. We don't want that to happen in this case, so the
@@ -112,13 +95,6 @@
 stream attributes can be specified for a tagged type T using the name of the
 stream attribute followed by 'Class; such class-wide aspects are not inherited
 for other descendants of T.
-
-The subprogram name given in such an @fa<attribute_definition_clause> or
-@fa< aspect_specification> shall statically denote a subprogram that is not an
-abstract subprogram. Furthermore, if a stream-oriented attribute is specified
-for an interface type, the subprogram name given in the
-@fa<attribute_definition_clause> or @fa<aspect_specification> shall statically
-denote a null procedure.
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent