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

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0102-1.txt

--- ai05s/ai05-0102-1.txt	2008/07/04 01:52:17	1.2
+++ ai05s/ai05-0102-1.txt	2009/07/11 03:06:22	1.3
@@ -1,6 +1,10 @@
-!standard 4.6(24.12/2)                                   08-07-03  AI05-0102-1/02
-!standard 5.2(11)
+!standard 3.7(16)                                      09-06-27  AI05-0102-1/03
+!standard 3.7.1(9)
+!standard 6.4.1(6)
+!standard 8.6(27)
 !class binding interpretation 08-06-15
+!status Amendment 201Z 09-06-27
+!status ARG Approved  7-0-0  09-06-13
 !status work item 08-06-15
 !status received 06-04-24
 !priority Low
@@ -33,8 +37,10 @@
 
 !wording
 
-Add after 8.6(32):
+Delete 3.7(16), 3.7.1(9), and 6.4.1(6).
 
+Add after 8.6(27):
+
 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).
 
@@ -54,10 +60,11 @@
 
 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 appears to have been an early Ada 95 attempt to fix this problem.
-(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.)
+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
@@ -68,21 +75,43 @@
 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.
+
+The new rule should be indexed to "implicit conversion, legality" and to
+"convertible (required)" (the latter to match the existing rules).
+
+!corrigendum 3.7(16)
+
+@ddel
+The type of the @fa<default_expression>, if any,
+for an access discriminant shall be convertible to the anonymous access type of
+the discriminant (see 4.6).
+
+!corrigendum 3.7.1(9)
+
+@ddel
+The @fa<expression> associated with an access
+discriminant shall be of a type convertible to the anonymous access type.
+
+!corrigendum 6.4.1(6)
 
-The three existing rules (3.7(16), 3.7.1(9), and 6.4.1(6)) can then be
-marked as redundant in the AARM. The new rule should be indexed to
-"implicit conversion, legality" and to "convertible (required)" (the
-latter to match the existing rules).
+@ddel
+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(32)
+!corrigendum 8.6(27)
 
 @dinsa
-A complete context that is a @fa<pragma_argument_association> is allowed to
-be ambiguous (unless otherwise specified for the particular pragma), but only
-if every acceptable interpretation of the pragma argument is as a @fa<name>
-that statically denotes a callable entity. Such a @fa<name> denotes all of
-the declarations determined by its interpretations, and all of the views
-declared by these declarations. 
+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.
+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>.
 @dinst
 If the expected type of a construct is @i<T1> and the actual type of the construct
 is @i<T2>, then @i<T2> shall be convertible to @i<T1> (see 4.6).

Questions? Ask the ACAA Technical Agent