CVS difference for ai05s/ai05-0262-1.txt

--- ai05s/ai05-0262-1.txt	2011/07/28 01:53:15	1.1
+++ ai05s/ai05-0262-1.txt	2011/08/04 01:48:45	1.2
@@ -1,4 +1,5 @@
-!standard  5.5(9)                               11-07-27    AI05-0262-1/01
+!standard  5.5(9)                               11-08-03    AI05-0262-1/02
+!standard  6.1.1(0)
 !standard 13.11(21)
 !class presentation 11-07-27
 !status Amendment 2012 11-07-27
@@ -31,6 +32,17 @@
 Redundant[For details about the execution of a loop_statement with the
 iteration_scheme being for iterator_specification, see 5.5.2.]
 
+Modify 6.1.1(3/3):
+
+This aspect specifies a class-wide precondition for {an operation of a tagged type}[a
+callable entity] and its descendants; ...
+
+Modify 6.1.1(5/3):
+
+This aspect specifies a class-wide postcondition for {an operation of a tagged type}[a
+callable entity] and its descendants; ...
+
+
 Modify the start of 13.11(21.5/3):
 
 For [one]{each} of the calls of Allocate described above, P
@@ -41,8 +53,11 @@
 These wording changes seem to be an improvement in readability and
 understandability, but are not intended to change the meaning of the words,
 except in the case of clear mistakes. The latter are listed below:
+
+6.1.1(3/3, 5/3): the term "descendant" is not defined for subprograms, so the original
+wording is dubious. The formal definition in 6.1.1(18/3) is correct, but too wordy to use
+in this introductory text.
 
-[None yet.]
 
 !corrigendum 5.5(9)
 
@@ -65,6 +80,12 @@
 For details about the execution of a @fa<loop_statement> with the
 @fa<iteration_scheme> being @b<for> @fa<iterator_specification>, see 5.5.2.
 
+!corrigendum 6.1.1(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
 !corrigendum 13.11(21)
 
 @dinsa
@@ -178,6 +199,87 @@
 
 I think *one* is confusing here - it makes the reader wonder what about
 the others. I think it should say *each* instead - or am I missing something?
+
+****************************************************************
+
+!topic Possible incorrect terminology in 6.1.1
+!reference 6.1.1(3/3, 5/3), AARM 6.1.1(22.a/3)
+!from Adam Beneschan 11-07-28
+!discussion
+
+6.1.1(3/3) says about Pre'Class, "This aspect specifies a class-wide
+precondition for a callable entity and its descendants".  However,
+nowhere in the RM is a "descendant" of a callable entity defined.
+"Descendants" are defined for types, library units, and nodes in
+Containers.Multiway_Trees, but not for subprograms.  Also, aside from
+paragraphs 3 and 5, and possibly 22.a in the AARM, the term
+"descendant" is never used to refer to anything besides a type,
+library unit, or Multiway_Trees node.  Since paragraph 14 explains
+just what the semantics are, I don't think the meaning of the RM is
+unclear; but since paragraphs 3 and 5 are in a normative part of the
+RM, the language they use should probably be correct.  
+
+Side note: The glossary (appendix N) contains a definition of
+"descendant", but that definition covers only the meaning that applies
+to types, not the one that applies to library units.  I'm not sure if
+this is a problem.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, July 30, 2011  1:21 AM
+
+> 6.1.1(3/3) says about Pre'Class, "This aspect specifies a class-wide 
+> precondition for a callable entity and its descendants".  However, 
+> nowhere in the RM is a "descendant"
+> of a callable entity defined.
+> "Descendants" are defined for types, library units, and nodes in 
+> Containers.Multiway_Trees, but not for subprograms.  Also, aside from 
+> paragraphs 3 and 5, and possibly 22.a in the AARM, the term 
+> "descendant" is never used to refer to anything besides a type, 
+> library unit, or Multiway_Trees node.  Since paragraph 14 explains 
+> just what the semantics are, I don't think the meaning of the RM is 
+> unclear; but since paragraphs
+> 3 and 5 are in a normative part of the RM, the language they use 
+> should probably be correct.
+
+Actually, the normative description of class-wide aspects applied to subprograms
+(no entries can be primitive operations of a tagged type) is in
+13.3.1(28/3) [this paragraph number may have changed since draft 12]:
+
+If the aspect_mark includes 'Class, then:
+...
+if the associated entity is a primitive subprogram of a tagged type T, the
+specification applies to the corresponding primitive subprogram of all descendants
+of T.
+
+The wording in 6.1.1(3/3) and 6.1.1(5/3) is intended to be a more informal
+description. And I wouldn't call it "incorrect" (since the semantics are defined
+formally elsewhere), just "undefined".
+
+But I do agree that it is somewhat uncomfortable to have undefined terminology in
+the normative wording, especially as it is the first description of the aspects.
+Repeating 6.1.1(18/3) [probably was 14/3 in draft 12, but 6.1.1 was changed a lot
+in Edinburgh] isn't helpful and would potentially cause a maintenance problem.
+
+So I have no better idea than the current wording.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, August 2, 2011  11:16 AM
+
+How about:
+
+3/3
+Pre'Class
+This aspect specifies a class-wide precondition for an operation of a tagged
+type and its descendants; ...
+
+5/3
+Post'Class
+This aspect specifies a class-wide postcondition for an operation of a tagged
+type and its descendants; ...
 
 ****************************************************************