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

Differences between 1.3 and version 1.4
Log of other versions for file ai12s/ai12-0159-1.txt

--- ai12s/ai12-0159-1.txt	2015/03/26 04:54:17	1.3
+++ ai12s/ai12-0159-1.txt	2015/03/28 00:13:16	1.4
@@ -1,7 +1,8 @@
-!standard 3.5.9(6)                                     15-03-25  AI05-0159-1/02
+!standard 3.5.9(6)                                     15-03-27  AI05-0159-1/03
 !standard 6.1.1(7/4)
 !standard 6.1.1(26.4/4)
 !standard 6.1.1(37/4)
+!standard 6.1.1(38/4)
 !standard 6.3.1(12/4)
 !standard 6.3.1(13/4)
 !standard 6.4.1(5)
@@ -10,6 +11,7 @@
 !standard 6.4.1(6.28/4)
 !standard 6.4.1(6.29/4)
 !standard 6.4.1(13.1/4)
+!standard 7.3.2(5/4)
 !standard 7.3.2(10/4)
 !standard 7.3.2(21/4)
 !standard 7.3.2(22.1/4)
@@ -19,6 +21,8 @@
 !standard A(3.1/4)
 !standard A.18.10(2/4)
 !class binding interpretation 15-03-23
+!status Corrigendum 2015 15-03-26
+!status ARG Approved 8-0-2  15-03-26
 !status work item 15-03-23
 !status received 15-02-26
 !priority Low
@@ -35,7 +39,7 @@
 (1) There does not appear to be any resolution rule that applies to a
 digits_constraint. Should there be one? (Yes.)
 
-(2) In 7.3.2(10/4) and 7.3.2(22.1/4), are the commas in the right place? (No.)
+(2) In 6.1.1(38/4) and 7.3.2(22.1/4), are the commas in the right place? (No.)
 
 (3) There is a missing "the" in 7.3.2(21/4). Should it be added? (Yes.)
 
@@ -96,57 +100,51 @@
 
 !wording
 
-[Note: Remove the name of the reviewer once this is finished and approved. It's
-here to speed discussion during the phone meeting.]
-
 (1)
 
-Add after 3.5.9(6): [Brukardt]
+Add after 3.5.9(6):
 
 The simple_expression of a digits_constraint is expected to be of any integer
 type.
 
 (2)
-
-Modify 7.3.2(10/4): [Moore]
 
-After successful explicit initialization of the completion of a deferred
-constant with a part of type T, if the completion is inside the immediate scope
-of the full view of T[,] and the deferred constant is visible outside the
-immediate scope of T, the check is performed on the part(s) of type T;
-
-Modify 7.3.2(22.1/4): [Dismukes]
-
-For an invariant check on a value of type T1 based on a class-wide
-invariant expression inherited from an ancestor type T, any operations
-within the invariant expression that were resolved as primitive
-operations of the (notional) formal derived type NT[,] are{,} in the
-evaluation of the invariant expression for the check on T1{,} bound to
-the corresponding operations of type T1.
+Modify 6.1.1(38/4):
 
-[Editor's note: 6.1.1(38/4) has similar text; if we move the commas in this
-paragraph, we need to do it in that one as well.]
+The class-wide precondition check for a call to a subprogram or entry S
+consists solely of checking the class-wide precondition expressions that
+apply to the denoted callable entity (not necessarily to the one that is
+invoked). Any operations within such an expression that were resolved as
+primitive operations of the (notional) formal derived type NT[,] are in the
+evaluation of the precondition bound to the corresponding operations of the
+type identified by the controlling tag of the call on S. This applies to
+both dispatching and non-dispatching calls on S.
+
+Modify 7.3.2(22.1/4):
+
+For an invariant check on a value of type T1 based on a class-wide invariant
+expression inherited from an ancestor type T, any operations within the
+invariant expression that were resolved as primitive operations of the
+(notional) formal derived type NT[,] are{ bound to the corresponding
+operations of type T1} in the evaluation of the invariant expression for the
+check on T1[ bound to the corresponding operations of type T1].
 
 (3)
 
-Modify 7.3.2(21/4): [Moore]
+Modify 7.3.2(21/4):
 
 If performing checks is required by the Type_Invariant or Type_Invariant'Class
 assertion policies (see 11.4.2) in effect at the point of {the} corresponding
 aspect specification applicable to a given type, then the respective invariant
 expression is considered enabled.
 
-[Editor's note: Sadly, this word is missing from the unchanged part of the
-paragraph. It was a last-minute change in Ada 2012 that presumably didn't get
-reviewed enough. Thus this trivial change appears here.]
-
 (4)
 
-Modify A.18.10(2/4): [Barnes]
+Modify A.18.10(2/4):
 
 A multiway tree container object manages a tree of nodes,
-{consisting}[comprising] of a root node {(see below)}, and {also} a set of
-internal nodes each of which contains an element and pointers to the parent,
+{consisting}[comprising] of a root node[,] and a set of internal nodes{;} each
+{internal node}[of which] contains an element and pointers to the parent,
 first child, last child, next (successor) sibling, and previous (predecessor)
 sibling internal nodes. A cursor designates a particular node within a tree
 (and by extension the element contained in that node, if any). A cursor keeps
@@ -155,7 +153,7 @@
 
 (5)
 
-Modify A(3.1/4): [Barnes, Dismukes]
+Modify A(3.1/4):
 
 For the purpose of determining whether concurrent calls on text input-output
 subprograms are required to perform as specified above, when calling a
@@ -165,7 +163,7 @@
 
 (6)
 
-Modify 11.3(4.1/4): [Taft, Barnes]
+Modify 11.3(4.1/4):
 
 If the evaluation of a string_expression or string_simple_expression raises an
 exception, that exception is propagated {instead of}[rather than] the one
@@ -173,17 +171,14 @@
 
 (7)
 
-Modify 11.3(3/4): [Taft]
+Modify 11.3(3/4):
 
-[An exception_name]{The exception_name, if any} of a raise_statement
+[An exception_name]{The exception_name, if any,} of a raise_statement
 or raise_expression ...
 
-[Editor's note: Careful: if we don't use "if any" here, revisit the wording
-of 11.3(3.1/4), which also uses "if any" after Editorial Review.]
-
 (8)
 
-Replace 11.3(3.2/4) by: [Taft]
+Replace 11.3(3.2/4) by:
 
    The expected type for a raise_expression shall be any single type.
 
@@ -197,80 +192,91 @@
 had a (notional) type NT that is a formal derived type whose ancestor 
 type is T, with directly visible primitive operations. Similarly, a 
 name that denotes a formal access parameter (or S'Result) of type 
-access-to-T is interpreted as having type access-to-NT. [The result of 
+access-to-T is interpreted as having type access-to-NT. The result of 
 this interpretation is that the only operations that can be applied to 
-such names are those defined for such a formal derived type. This 
+such names are those defined for such a formal derived type. [This 
 ensures that the expression is well-defined for any primitive 
 subprogram of a type descended from T.]
 
 Add an AARM note:
 
-Reason: The result of this interpretation is that the only operations
-that can be applied to  such names are those defined for such a formal
-derived type. This  ensures that the expression is well-defined for
+Reason: This ensures that the expression is well-defined for
 any primitive subprogram of a type descended from T.
 
-[Editor's note: 7.3.2(5/4) has the same wording, which should get the same
-treatment, if any. See discussion.]
+Modify 7.3.2(5/4):
 
+Within an invariant expression, the identifier of the first subtype of the
+associated type denotes the current instance of the type. Within an invariant
+expression for the Type_Invariant aspect of a type T, the type of this the
+current instance is T. Within an invariant expression for the
+Type_Invariant'Class aspect of a type T, the type of this current instance
+is interpreted as though it had a (notional) type NT that is a visible formal
+derived type whose ancestor type is T. The effect of this interpretation is
+that the only operations that can be applied to this current instance are 
+those defined for such a formal derived type.[ This ensures that the invariant
+expression is well-defined for any type descended from T.].
+Add an AARM note:
+
+Reason: This ensures that the expression is well-defined for
+any type descended from T.
+
 (10)
 
-Modify 6.3.1(12/4): [Ploedereder]
+Modify 6.3.1(12/4):
 
 * The default calling convention is *protected* for a protected 
   subprogram, {for} a prefixed view of a subprogram with a synchronization 
   kind of By_Protected_Procedure, and for an access-to-subprogram type 
   with the reserved word protected in its definition.
 
-Modify 6.3.1(13/4): [Baird]
+Modify 6.3.1(13/4):
 * The default calling convention is *entry*
   for an entry and {for} a prefixed view of a subprogram with
   a synchronization kind of By_Entry.
 
 (11)
 
-Move 6.4.1(6.26-6.29/4) after 6.4.1(5). [Ploedereder]
+Move 6.4.1(6.26-6.29/4) after 6.4.1(5).
 
 (12)
 
-Modify 6.3.1(13.1/4): [Ploedereder]
+Modify 6.4.1(13.1/4):
 
 * For a scalar type that has the Default_Value aspect specified, the 
   formal parameter is initialized from the value of the actual, without 
   checking that the value satisfies any constraint or any predicate{.
-  If, however, }[, except in the following case: if] the actual parameter is
+  Furthermore, }[, except in the following case:] if the actual parameter is
   a view conversion and either
 
 (13)
 
-Modify 6.1.1(26.4/4): [Baird]
+Modify 6.1.1(26.4/4):
 
  * If X is of an anonymous access {type} defined by an access_definition
    A then
 
 (14)
 
-Modify 6.1.1(37/4): [Baird]
+Modify 6.1.1(37/4):
 
-For any {call to a} subprogram or entry [call] S (including dispatching
-calls), the checks
-that are performed to verify specific precondition expressions and specific
-and class-wide postcondition expressions are determined by those for the
-subprogram or entry actually invoked. Note that the class-wide postcondition
-expressions verified by the postcondition check that is part of a call on a
-primitive subprogram of type T includes all class-wide postcondition
-expressions originating in any progenitor of T, even if the primitive
-subprogram called is inherited from a type T1 and some of the postcondition
-expressions do not apply to the corresponding primitive subprogram of T1.
-Any operations within a class-wide postcondition expression that were
-resolved as primitive operations of the (notional) formal derived type NT,
-are in the evaluation of the postcondition bound to the corresponding
+For any {call to a} subprogram or entry [call] S (including dispatching calls),
+the checks that are performed to verify specific precondition expressions and
+specific and class-wide postcondition expressions are determined by those for
+the subprogram or entry actually invoked. Note that the class-wide
+postcondition expressions verified by the postcondition check that is part of
+a call on a primitive subprogram of type T includes all class-wide
+postcondition expressions originating in any progenitor of T, even if the
+primitive subprogram called is inherited from a type T1 and some of the
+postcondition expressions do not apply to the corresponding primitive
+subprogram of T1. Any operations within a class-wide postcondition expression
+that were resolved as primitive operations of the (notional) formal derived
+type NT, are in the evaluation of the postcondition bound to the corresponding
 operations of the type identified by the controlling tag of the call on
 S. This applies to both dispatching and non-dispatching calls on S.
 
 (15)
 
-Modify 4.1.4(9/4): [Baird]
+Modify 4.1.4(9/4):
 
 An attribute_reference denotes a value, an object, a subprogram, or some
 other kind of program entity. Unless explicitly specified otherwise, for 
@@ -292,81 +298,83 @@
 
 (2) Comma madness. :-)
 
-(3) Helps to edit. ;-)
+(3) Helps to edit. ;-) This is in part of the paragraph introduced by a
+last-minute change in the Ada 2012 wording.
 
 (4) "comprising of" is just weird. The comma after "root node" is also weird,
 but it is very important to the meaning (as the contents of the "root node"
 are defined in the next paragraph, it's not the list following "internal node").
-Thus we adjust the wording to clarify that, and leave the comma in place.
+Thus we break the sentence into two parts so that we no longer need the comma,
+by repeating the part about the internal nodes.
 
 (5) The standard usually uses "input-output" to describe files, libraries, etc.,
 not "input/output".
 
-(6) The RM/AARM uses "rather than" more often than "instead of". (175 occurrences
-to 55) Still, "instead of" sounds better to the Editor's ear as well as the
-commenter.
+(6) The RM/AARM uses "rather than" more often than "instead of". (175
+occurrences to 55) Still, "instead of" sounds better to the Editor's ear as
+well as the commenter. The commenter suggests that "rather than" best applies
+to a substitute action, and "instead of" best applies to a substitute object.
+For example: He kicked rather than hit the ball.  He hit the ball instead of
+the balloon. And this sentence is talking about replacing the object (an
+exception) rather than replacing the action (propagation).
 
 (7) The wording was changed from the original "if any" wording (which is now the
 new wording), to the "An" wording, during discussion during the Stockholm ARG
 meeting. The objection appears to have been that the exception_name is not
-optional for a raise_expression, so "if any" is weird.
+optional for a raise_expression, so "if any" is weird. However, the "An"
+wording seems to imply that there can be more than one, so it isn't clearly
+better.
 
-Reverting the wording of course also brings back the objection. We'll have to
-discuss this to see which is stronger.
-
 (8) The suggested wording is similar to the way aggregates and string literals
 work, other entities that themselves do not provide a type.
-
-(9) The last sentence of 6.1.1(7/4) comes unmodified from Ada 2012 text.
-The penultimate sentence was added to explain the last sentence. If the last
-sentence was valuable for Ada 2012, it's even more valuable now, as the
-semantics are less intuitive.
-
-An alternative would a user note, but of course that is not near the rules
-in question.
-
-The author of this AI would rather not make this change, but it's a close call.
-
-(10) These are uninitended inconsistencies in wording.
-
-(11) In addition to the reason given in the question, the reviewer gave two
-additional reasons to move this text. First, he notes that paragraphs 6 all the
-way to 6.25 talks about alias rules, while the new text is about initialization.
 
-There are several unrelated rules in that large clump of text; in particular the
-first 5 paragraphs are about aliased parameters while the rest are about
-anti-aliasing in calls.
+This is incompatible in weird cases. For instance, this bans raise expressions
+from being the operand of a type conversion (a qualified expression should
+be used instead). This appears to include the case where a type conversion is
+distributed to the operands of a conditional expression:
+T(if A then B else raise Constraint_Error) is illegal by this rule.
 
-Indeed, the best place to move these rules would be after 6.4.1(6.4/3), except
-for the fact that inserting them there would change all of the paragraph
-numbers following (we don't allow inserts of inserts for paragraph numbers).
-
-The reviewer also stated that it remains unclear to which rules the "these rules
-also apply"-boilerplate is referring: only to the last two bullets or to all
-the aliasing rules as well.
+(9) The last sentence of 6.1.1(7/4) comes unmodified from Ada 2012 text.
 
-While this is true, with one well-known exception, the boilerplate can and
-probably should apply to all Legality Rules. For many rules (those that can't
-depend in any way on the properties of a generic formal), it doesn't matter
-either way. For the rest, experience says that they almost always have to be
-rechecked. So this is a weak reason to move the rules.
+We considered adding a user note, but of course that is not near the rules
+in question. Thus it would come too late to really be helpful in explaining
+the changes.
+
+(10) These are unintended inconsistencies in wording. Most of the 6.3.1 bullets
+are written in the form of "the calling convention for <something> is
+<some-convention>".
+
+(11) These rules do get lost after the anti-aliasing rules, they should have
+more visibility.
+
+The best place to move these rules would be after 6.4.1(6.4/3), since that
+is the last rule other than the anti-aliasing rules. But inserting them there
+would change all of the paragraph numbers following (we don't allow inserts of
+inserts for paragraph numbers). We don't want to do that.
 
-Still, after 6.4.1(5) is the only sensible alternative for the placement of
-these rules. It's either there or leave them where they are.
+So, after 6.4.1(5) is the only sensible alternative for the placement of
+these rules.
 
 (12) Since this additional text specifies an additional, non-optional check,
 it doesn't really matter to which it applies, other than the part about
-"for a scalar type with Default_Value specified". Thus separating it as
+"for a scalar type with Default_Value specified". Whether a parameter that
+fails this check is initialized cannot be determined (the parameter could not
+be read), and initialization cannot raise an exception. Thus separating it as
 suggested (or even making it a separate paragraph under the same bullet) is
 OK.
 
 (13) "anonymous access" by itself doesn't mean anything, it needs to modify
-something. In this case, that's a type.
+something. In this case, that's a type. Arguably, that can be inferred from
+the fact that an access_definition (which declares an anonymous type) is
+involved, but it's better to be explicit.
 
 (14) The questioner is correct about the change in meaning of S. The wording
 should be fixed.
 
-(15)
+(15) We certainly don't mean to include predicates in this case, so we need
+to explicit mention that they don't apply (two places). This is clearly an
+omission.
+
 
 !corrigendum 3.5.9(6)
 

Questions? Ask the ACAA Technical Agent