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

--- ai05s/ai05-0102-1.txt	2009/07/11 03:06:22	1.3
+++ ai05s/ai05-0102-1.txt	2009/10/15 04:20:17	1.4
@@ -1,7 +1,7 @@
-!standard 3.7(16)                                      09-06-27  AI05-0102-1/03
+!standard 3.7(16)                                      09-10-12  AI05-0102-1/04
 !standard 3.7.1(9)
 !standard 6.4.1(6)
-!standard 8.6(27)
+!standard 8.6(27/2)
 !class binding interpretation 08-06-15
 !status Amendment 201Z 09-06-27
 !status ARG Approved  7-0-0  09-06-13
@@ -39,7 +39,7 @@
 
 Delete 3.7(16), 3.7.1(9), and 6.4.1(6).
 
-Add after 8.6(27):
+Add after 8.6(27/2):
 
 If the expected type of a construct is T1 and the actual type of the construct
 is T2, then T2 shall be convertible to T1 (see 4.6).
@@ -61,23 +61,23 @@
 4.6 defines the term "convertible" for rules like this. Indeed, some
 implicit conversion contexts (3.7, 3.7.1, and 6.4.1) already have legality
 rules. This was an Ada 95 attempt to fix this problem; these are the only
-places where mismatches are possible. (Ada 95 ultimately did not have this
-problem, as resolution did not allow an access-to-constant value to match
-an anonymous access type. But that will not work for Ada 2005, as we now
-have anonymous access-to-constant types.)
-
-We could try a similar fix for Ada 2005. However, the index lists 30 places
-that use implicit conversion, and it would be silly to add legality rules in
-27 more places. Besides the sheer volume of change, there would be a lingering
-maintenance problem where any new implicit conversion contexts could easily
-forget to add the needed legality rule.
+places where mismatches were possible in Ada 95. (Ada 95 ultimately did not
+have this problem, as resolution did not allow an access-to-constant value
+to match an anonymous access type. But that will not work for Ada 2005, as
+we now have anonymous access-to-constant types.)
+
+We could try a similar fix for Ada 2005. However, the index lists more than
+30 places that use implicit conversion, and it would be silly to add legality
+rules in that many more places. Besides the sheer volume of change, there would
+be a lingering maintenance problem where any new implicit conversion contexts
+could easily forget to add the needed legality rule.
 
 Implicit conversion is implicitly defined in 8.6 (by the definition of
 which types match an expected type T). So that seems to be the best
 place for a blanket legality rule.
 
 The three existing rules (3.7(16), 3.7.1(9), and 6.4.1(6)) are then removed,
-as there is no value to having special rules in 3 out of 30 cases.
+as there is no value to having special rules in 3 out of more than 30 cases.
 
 The new rule should be indexed to "implicit conversion, legality" and to
 "convertible (required)" (the latter to match the existing rules).
@@ -101,14 +101,13 @@
 The type of the actual parameter associated with an access parameter
 shall be convertible (see 4.6) to its anonymous access type.
 
-!corrigendum 8.6(27)
+!corrigendum 8.6(27/2)
 
 @dinsa
-When the expected type for a construct is one that requires that its expected type
-required to be a @i<single type> in a given class, the type of expected for the
-construct shall be determinable solely from the context in which the construct
-appears, excluding the construct itself, but using the requirement that it be in
-the given class; the type of the construct is then this single expected type.
+When a construct is one that requires that its expected type be a @i<single type>
+in a given class, the type of the construct shall be determinable solely from the
+context in which the construct appears, excluding the construct itself, but using
+the requirement that it be in the given class.
 Furthermore, the context shall not be one that expects any type in some class that
 contains types of the given class; in particular, the construct shall not be the
 operand of a @fa<type_conversion>.