CVS difference for ai05s/ai05-0149-1.txt
--- ai05s/ai05-0149-1.txt 2009/11/04 01:44:07 1.7
+++ ai05s/ai05-0149-1.txt 2009/12/18 07:16:16 1.8
@@ -1,8 +1,10 @@
-!standard 4.5.2(30.2/2) 09-11-03 AI05-0149-1/05
-!standard 8.6(24)
+!standard 4.5.2(30.2/2) 09-12-17 AI05-0149-1/06
!standard 8.6(25/2)
!standard 8.6(27/2)
+!standard 8.6(29)
!class Amendment 09-04-12
+!status Amendment 201Z 09-12-17
+!status ARG Approved 7-1-3 09-11-07
!status work item 09-04-12
!status received 09-04-12
!priority Medium
@@ -17,15 +19,15 @@
There is currently no way to check whether a conversion from an
anonymous access type to a named access type will pass its run-time
-accessibility check. Normally a membership test can be used prior to a
+accessibility check. Normally a membership test can be used prior to a
conversion to check if the conversion will succeed, but the current
rules for access-type membership tests don't allow for this.
If an access type is made visible via a limited with, it can't be used
in the client package to declare variables or components, since it is an
-incomplete type. (Note that in AI05-0151 we dicuss the possibility of using
+incomplete type. (Note that in AI05-0151 we discuss the possibility of using
incomplete types for parameters and results.) In this case, it might be
-natural to use anonymous access types in the client package. However,
+natural to use anonymous access types in the client package. However,
these anonymous access types then need to be converted to the named
access type at some point, and that currently requires an explicit
conversion. It would be preferable if safe conversions from an
@@ -35,7 +37,7 @@
to a named access-to-classwide type that is certain to succeed the
tag check (i.e., is a "widening" conversion). This would reduce
the need for anonymous access types in general, which is considered
-probably a good thing.
+probably a good thing. (Actually, there is a reason.)
!proposal
@@ -51,7 +53,7 @@
designated type is tagged, the designated type of the anonymous
access type shall be covered by the designated type of the named
access type (explicit conversion allows for more possibilities).
-
+
!wording
Add after 4.5.2(30.2/2):
@@ -63,46 +65,48 @@
non-null, the tag of the object designated by the value of the
simple_expression is covered by the designated type of the tested type.
-Revise 8.6(22-25.1) as follows:
+Revise 8.6(22-25.1/2) as follows:
- * If the expected type for a construct is a specific type T, then the
- type of the construct shall resolve either to T, or:
+ * If the expected type for a construct is a specific type T, then the
+ type of the construct shall resolve either to T, or:
- - to T'Class; or
+ - to T'Class; or
- to a universal type that covers T; or
-
- - when T is a specific anonymous access-to-object type (see 3.10)
+
+ - when T is a specific anonymous access-to-object type (see 3.10)
with designated type D, to an access-to-object type whose
designated type is D'Class or is covered by D; or
- {AARM Ramification: D'Class will only be legal as part of a call on a
- dispatching operation; see 3.9.2(9), "Dispatching Operations of Tagged
- Types". Note that this rule is not a Name Resolution Rule.}
-
+ AARM Ramification: The case where the actual is access-to-D'Class will
+ only be legal as part of a call on a dispatching operation; see
+ 3.9.2(9), "Dispatching Operations of Tagged Types". Note that
+ this rule is not a Name Resolution Rule.
+
{- when T is a named general access-to-object type (see 3.10) with
designated type D, to an anonymous access-to-object
- type whose designated type is covered by D; or}
+ type whose designated type covers or is covered by D; or}
[NOTE to ARG: this is relevant to both parts (1) & (2)]
-
- - when T is an anonymous access-to-subprogram type (see 3.10),
- to an access-to-subprogram type whose designated profile is
+
+ - when T is an anonymous access-to-subprogram type (see 3.10),
+ to an access-to-subprogram type whose designated profile is
type-conformant with that of T.
-Add after 8.6(27):
+Add after 8.6(27/2):
Other than for the simple_expression of a membership test, if the
expected type for a name or expression is not the same as the actual
type of the name or expression, the actual type shall be convertible
to the expected type (see 4.6); further, if the expected type is a
- named access-to-object type and the actual type is an anonymous
- access-to-object type, then the name or expression shall denote a view
+ named access-to-object type with designated type D1 and the actual type
+ is an anonymous access-to-object type with designated type D2, then D1 shall
+ cover D2, and the name or expression shall denote a view
with an accessibility level for which the statically deeper
relationship applies [Redundant: ; in particular it shall not denote
an access parameter nor a standalone access object].
- {AARM NOTE: This is to minimize cases of implicit conversions when
- the accessibility check cannot be performed at compile-time. We word
+ AARM NOTE: This is to minimize cases of implicit conversions when
+ the the tag check or the accessibility check might fail. We word
this this way because access discriminants should also be disallowed
- if their enclosing object is designated by an access parameter.}
+ if their enclosing object is designated by an access parameter.
Modify 8.6(29) by adding a preference rule for universal_access equality:
@@ -122,7 +126,7 @@
from an anonymous access type to a named access type, which would
allow the equality operator of any named access type to be used
to compare anonymous access values.}
-
+
!discussion
We have grouped part (1) with proposal (2) as any changes to
@@ -157,7 +161,7 @@
anonymous access types to named access types for everything *but*
parameters. For parameters, AI05-0151 allows the original (incomplete)
named access type to be used as a formal parameter type in the client
-package, rather than having to resort to an anonymous access type.
+package, rather than having to resort to an anonymous access type.
Using anonymous access types for formal parameters introduces additional
dynamic accessibility checks, whereas using the named access type
directly avoids that.
@@ -194,7 +198,7 @@
is "null" or an allocator. The extent of this ambiguity should be
investigated if possible in existing archives of customer code. Note
that this applies to some extent to both proposals (2) and the rejected
-proposal (3) (see below), though more so to (3), as existing code could
+proposal (3) (see below), though more so to (3), as existing code could
never pass an anonymous access type to a formal that is of a named access type.
Note that we have added a preference rule for the equality operators
@@ -225,38 +229,111 @@
A, B : T1 := ...;
- A_eq_B : Boolean := A = B; -- Ambigious (T1."=", T2."=", Standard."=")
+ A_eq_B : Boolean := A = B; -- Ambiguous (T1."=", T2."=", Standard."=")
-A preference rule would introduce Beaujolais effects or would cause any
-user-defined "=" operators to be ignored. That's both bad and
-incompatible; not trying to fix the problem would make "=" essentially
-unusable. So further expansion of implicit conversion is not possible.
+A preference rule to T1."=" would introduce Beaujolais effects. That's bad.
+A preference rule to Standard."=" would cause any user-defined "=" operators
+to be ignored. That's both bad and incompatible. Not trying to fix the problem
+would make "=" essentially unusable. So further expansion of implicit conversion
+is not possible.
!example
type Acc is access T;
- type Class_Acc is access T'Class;
-
+ type Class_Acc is access T'Class;
+
procedure P(X : access T) is
Y : Acc;
Z : Class_Acc;
- begin
+ begin
Y := X; -- Illegal implicit conversion, since X is an access parameter.
Y := Acc(X); -- Legal, might raise Program_Error
-
+
if X in Acc then
Y := Acc(X); -- Known to be safe now
else
Y := null;
end if;
-
+
Z := Y; -- Legal implicit conversion
-
+
Y := Z; -- Illegal implicit conversion
end P;
+!corrigendum 4.5.2(30.2/2)
+@drepl
+@xbullet<if the tested type is an access type and the named subtype excludes null,
+the value of the @fa<simple_expression> is not null.>
+@dby
+@xbullet<if the tested type is an access type and the named subtype excludes null,
+the value of the @fa<simple_expression> is not null;>
+
+@xbullet<if the tested type is a general access-to-object type, the type of the
+@fa<simple_expression> is convertible to the tested type and its
+accessibility level is no deeper than that of the tested type;
+further, if the designated type is tagged and the @fa<simple_expression> is
+non-null, the tag of the object designated by the value of the
+@fa<simple_expression> is covered by the designated type of the tested type.>
+
+!corrigendum 8.6(25/2)
+
+@dinsa
+@xinbull<when @i<T> is a specific anonymous access-to-object type (see 3.10)
+with designated type @i<D>, to an access-to-object type whose designated type
+is @i<D>'Class or is covered by @i<D>; or>
+@dinst
+@xinbull<when @i<T> is a named general access-to-object type (see 3.10) with
+designated type @i<D>, to an anonymous access-to-object
+type whose designated type covers or is covered by @i<D>; or>
+
+!corrigendum 8.6(27/2)
+
+@dinsa
+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>.
+@dinst
+Other than for the @fa<simple_expression> of a membership test, if the
+expected type for a @fa<name> or @fa<expression> is not the same as the actual
+type of the @fa<name> or @fa<expression>, the actual type shall be convertible
+to the expected type (see 4.6); further, if the expected type is a
+named access-to-object type with designated type @i<D1> and the actual type
+is an anonymous access-to-object type with designated type @i<D2>, then @i<D1>
+shall cover @i<D2>, and the @fa<name> or @fa<expression> shall denote a view
+with an accessibility level for which the statically deeper
+relationship applies; in particular it shall not denote
+an access parameter nor a standalone access object.
+
+!corrigendum 8.6(29)
+
+@drepl
+There is a @i<preference> for the primitive operators (and @fa<range>s) of
+the root numeric types @i<root_integer> and @i<root_real>. In particular,
+if two acceptable interpretations of a constituent of a complete context
+differ only in that one is for a primitive operator (or @fa<range>) of the
+type @i<root_integer> or @i<root_real>, and the other is not, the
+interpretation using the primitive operator (or @i<range>) of the root
+numeric type is @i<preferred>.
+@dby
+There is a @i<preference> for the primitive operators (and @fa<range>s) of
+the root numeric types @i<root_integer> and @i<root_real>. In particular,
+if two acceptable interpretations of a constituent of a complete context
+differ only in that one is for a primitive operator (or @fa<range>) of the
+type @i<root_integer> or @i<root_real>, and the other is not, the
+interpretation using the primitive operator (or @i<range>) of the root
+numeric type is @i<preferred>. Similarly, there is a preference for the
+equality operators of the @i<universal_access> type (see 4.5.2). If two
+acceptable interpretations of a constituent of a complete context
+differ only in that one is for an equality operator of the
+@i<universal_access> type, and the other is not, the interpretation using
+the equality operator of the @i<universal_access> type is preferred.
+
!ACATS test
ACATS C-Tests are needed to check that this membership and these implicit
@@ -1224,3 +1301,76 @@
****************************************************************
+From: Tucker Taft
+Sent: Saturday, November 7, 2009 6:51 PM
+
+ I realized shortly after we finished the discussion on AI05-149 that I must
+have unintentionally lost something when I removed the third part of
+AI05-149 (the part that Bob liked), because now the implicit conversion rules
+are too strict for the purposes of the membership test.
+
+We really want to be able to write something like:
+
+ type T2 is new T with ...
+ type T3 is new T2 with ...
+ type T3_Ptr is access all T3'Class;
+
+ function F(X : access T'Class) return T3_Ptr is
+ begin
+ if X in T3_Ptr then
+ return T3_Ptr(X);
+ else
+ return null;
+ end if;
+ end F;
+
+But the latest proposed rules in 8.6(22-25.1) don't allow the case where the
+designated type of X covers the designated type of the tested type, as it does
+above. Hence, I think we need to change the proposed wording as follows.
+Insertions are {{}} and deletions are [[]], relative to the current state of the
+AI:
+
+Revise 8.6(22-25.1) as follows:
+
+ * If the expected type for a construct is a specific type T, then the
+ type of the construct shall resolve either to T, or:
+
+ - to T'Class; or
+
+ - to a universal type that covers T; or
+
+ - when T is a specific anonymous access-to-object type (see 3.10)
+ with designated type D, to an access-to-object type whose
+ designated type is D'Class or is covered by D; or
+ {AARM Ramification: D'Class will only be legal as part of a call on a
+ dispatching operation; see 3.9.2(9), "Dispatching Operations of Tagged
+ Types". Note that this rule is not a Name Resolution Rule.}
+
+ {- when T is a named general access-to-object type (see 3.10) with
+ designated type D, to an anonymous access-to-object
+ type whose designated type {{covers or}} is covered by D; or}
+ [NOTE to ARG: this is relevant to both parts (1) & (2)]
+
+ - when T is an anonymous access-to-subprogram type (see 3.10),
+ to an access-to-subprogram type whose designated profile is
+ type-conformant with that of T.
+
+Add after 8.6(27):
+
+ Other than for the simple_expression of a membership test, if the
+ expected type for a name or expression is not the same as the actual
+ type of the name or expression, the actual type shall be convertible
+ to the expected type (see 4.6); further, if the expected type is a
+ named access-to-object type {{with designated type D1}} and the actual type
+ is an anonymous access-to-object type {{with designated type D2,}} then {{D1
+ shall cover D2, and}} the name or expression shall denote a view
+ with an accessibility level for which the statically deeper
+ relationship applies [Redundant: ; in particular it shall not denote
+ an access parameter nor a standalone access object].
+ {AARM NOTE: This is to minimize cases of implicit conversions when
+ {{the tag check or}} the accessibility check {{might fail}}
+ [[cannot be performed at compile-time]]. We word
+ this this way because access discriminants should also be disallowed
+ if their enclosing object is designated by an access parameter.}
+
+****************************************************************
Questions? Ask the ACAA Technical Agent