CVS difference for 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 3.7(16) 09-06-27 AI05-0102-1/03
!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
@@ -33,8 +37,10 @@
-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).
+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).
+The @fa<expression> associated with an access
+discriminant shall be of a type convertible to the anonymous access type.
-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).
+The type of the actual parameter associated with an access parameter
+shall be convertible (see 4.6) to its anonymous access type.
-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>.
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