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

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

--- ai05s/ai05-0102-1.txt	2008/06/16 04:10:59	1.1
+++ ai05s/ai05-0102-1.txt	2008/07/04 01:52:17	1.2
@@ -1,4 +1,4 @@
-!standard 4.6(24.12/2)                                   08-06-15  AI05-0102-1/01
+!standard 4.6(24.12/2)                                   08-07-03  AI05-0102-1/02
 !standard 5.2(11)
 !class binding interpretation 08-06-15
 !status work item 08-06-15
@@ -10,7 +10,8 @@
+A legality rule is added to 8.6 to ensure that all implicit conversions
+are between types that are convertible.
@@ -32,24 +33,64 @@
-** TBD.
+Add after 8.6(32):
+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).
-The only way to see this as illegal now is to use the dynamic semantics
-rule 5.2(11), which says that the result is converted, and then note
-that 4.6(24.12/2) says that this conversion is illegal. But it is very
-unconfortable depending on a dynamic semantics rule to trigger a legality
-error, especially as the rule talks about raising an exception but not
-an error.
+AARM Reason: This is needed to prevent implicit conversions which would be
+illegal if they were explicit conversions. For instance, we do not want
+to implicitly convert an access-to-constant value to an anonymous
+access-to-variable type. We do not want to make the resolution rules
+specific enough to prevent these sorts of issues, so we need a separate
+legality rule.
-The way forward is not clear here (there are other places than assignment
-that need to be considered).
---!corrigendum 5.2(11)
+5.2 has no legality rule that applies in this case. The closest we have
+is 5.2(11), which is a dynamic semantics rule, and it is uncomfortable
+to have legality depending on a dynamic rule. Thus, a new legality rule
+is needed somewhere. 
+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.)
+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.
+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)) 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).
+!corrigendum 8.6(32)
+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. 
+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).
 !ACATS Test
+An ACATS test should check that implicit conversions like the one in the
+question are illegal.

Questions? Ask the ACAA Technical Agent