CVS difference for ais/ai-00127.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00127.txt

--- ais/ai-00127.txt	1998/09/30 00:17:21	1.1
+++ ais/ai-00127.txt	1999/06/26 01:11:13	1.2
@@ -1,5 +1,6 @@
-!standard 03.10.02 (27)                               96-11-16  AI95-00127/04
+!standard 03.10.02 (27)                               99-06-25  AI95-00127/05
 !class binding interpretation 96-04-04
+!status Corrigendum 2000 99-05-25
 !status WG9 approved 96-12-07
 !status ARG approved 8-0-4  96-10-07
 !status ARG approved (subj. ed. rev., letter ballot was 9-0-2) 96-10-03
@@ -10,7 +11,7 @@
 !difficulty Medium
 !subject Expected type of a 'Access attribute
 
-!summary 96-07-23
+!summary
 
 An attribute reference of the Access attribute may be used as the actual
 parameter in a dispatching call, if the formal is an access parameter
@@ -21,7 +22,7 @@
 An analogous rule applies to an attribute reference of Unchecked_Access,
 and to an allocator.
 
-!question 96-07-23
+!question
 
 Consider the following code fragment:
 
@@ -50,11 +51,11 @@
 It would seem that the same rules should apply to all of these calls;
 (1) and (2) should be legal, and should be dispatching calls.
 
-!recommendation 96-04-04
+!recommendation
 
 (See summary.)
 
-!wording 96-07-23
+!wording
 
 In the last sentence of 3.10.2(24), give a name to the designated type,
 so we can refer to it more easily in 3.10.2(27):
@@ -64,7 +65,7 @@
     the general access type A{, with designated type D}:
 
 Replace 3.10.2(27) with:
-    
+
     If A is named and D is tagged, then the type of the view shall be
     covered by D;
     If A is anonymous and D is tagged, then the type of the view shall be
@@ -102,12 +103,12 @@
     type, then the expression or name shall not be dynamically tagged unless
     it is a controlling operand in a call on a dispatching operation.
     Similarly, if the expected type for an expression is an anonymous
-    access-to-specific tagged type, then the expression shall not be 
+    access-to-specific tagged type, then the expression shall not be
     [of an access-to-class-wide type]{dynamically tagged}
     unless it designates a controlling operand in a call on a dispatching
     operation.
 
-!discussion 96-07-23
+!discussion
 
 The rules should be equivalent in these cases; anything else would be
 surprising to the programmer.  This is achieved by the above wording.
@@ -123,9 +124,109 @@
 
 No wording changes are needed for Unchecked_Access, since it is already
 defined in terms of Access.
+
+!corrigendum 3.09.02(7)
+
+@drepl
+A @fa<type_conversion> is statically or dynamically tagged according to whether
+the type determined by the @fa<subtype_mark> is specific or class-wide,
+respectively. For a controlling operand that is designated by an actual
+parameter, the controlling operand is statically or dynamically tagged
+according to whether the designated type of the actual parameter is specific
+or class-wide, respectively.
+@dby
+A @fa<type_conversion> is statically or dynamically tagged according to whether
+the type determined by the @fa<subtype_mark> is specific or class-wide,
+respectively. A controlling operand of the form X'Access, where X is of a
+class-wide type, is dynamically tagged. Similarly, a controlling operand of the
+form new T'(...), where T denotes a class-wide subtype, is dynamically tagged.
+For any other controlling operand that is designated by an actual parameter,
+the controlling operand is statically or dynamically tagged according to
+whether the designated type of the actual parameter is specific or class-wide,
+respectively.
+
+!corrigendum 3.09.02(9)
+
+@drepl
+If the expected type for an expression or @fa<name> is some specific tagged
+type, then the expression or name shall not be dynamically tagged unless it
+is a controlling operand in a call on a dispatching operation.  Similarly, if
+the expected type for an expression is an anonymous access-to-specific tagged
+type, then the expression shall not be of an access-to-class-wide type unless
+it designates a controlling operand in a call on a dispatching operation.
+@dby
+If the expected type for an expression or @fa<name> is some specific tagged
+type, then the expression or name shall not be dynamically tagged unless
+it is a controlling operand in a call on a dispatching operation.
+Similarly, if the expected type for an expression is an anonymous
+access-to-specific tagged type, then the expression shall not be
+dynamically tagged unless it designates a controlling operand in a call
+on a dispatching operation.
+
+!corrigendum 3.10.02(24)
+
+@drepl
+@xhang<X'Access
+X'Access yields an access value that designates the object
+denoted by X. The type of X'Access is an access-to-object
+type, as determined by the expected type. The expected type
+shall be a general access type. X shall denote an aliased
+view of an object, including possibly the current instance
+(see 8.6) of a limited type within its definition, or a
+formal parameter or generic formal object of a tagged type.
+The view denoted by the prefix X shall satisfy the following
+additional requirements, presuming the expected type for
+X'Access is the general access type @i<A>:>
+@dby
+@xhang<X'Access
+X'Access yields an access value that designates the object
+denoted by X. The type of X'Access is an access-to-object
+type, as determined by the expected type. The expected type
+shall be a general access type. X shall denote an aliased
+view of an object, including possibly the current instance
+(see 8.6) of a limited type within its definition, or a
+formal parameter or generic formal object of a tagged type.
+The view denoted by the prefix X shall satisfy the following
+additional requirements, presuming the expected type for
+X'Access is the general access type @i<A>, with designated type @i<D>:>
+
+!corrigendum 3.10.02(27)
+
+@drepl
+@xinbull<If the designated type of @i<A> is tagged, then the type of the view
+shall be covered by the designated type; if @i<A>'s designated type is not
+tagged, then the type of the view shall be the same, and either @i<A>'s
+designated subtype shall statically match the nominal subtype of the view,
+or the designated subtype shall be discriminated and unconstrained;>
+@dby
+@xinbull<If @i<A> is named and @i<D> is tagged, then the type of the view shall
+be covered by @i<D>; If @i<A> is anonymous and @i<D> is tagged, then the type
+of the view shall be either @i<D>'Class, or a type covered by @i<D>;
+If @i<D> is not tagged, then the type of the view shall be the same, and
+either A's designated subtype shall statically match the nominal
+subtype of the view, or the designated subtype shall be
+discriminated and unconstrained;>
+
+!corrigendum 4.08(03)
+
+@drepl
+The expected type for an allocator shall be a single access-to-object
+type whose designated type covers the type determined by the @fa<subtype_mark>
+of the @fa<subtype_indication> or @fa<qualified_expression>.
+@dby
+The expected type for an allocator shall be a single access-to-object type
+whose designated type covers the type determined by the @fa<subtype_mark> of
+the @fa<subtype_indication> or @fa<qualified_expression>, or, if the expected
+type is anonymous, whose designated type is the class-wide type corresponding
+to the determined type.
 
-!appendix 96-04-04
+!ACATS test
 
+A C-Test is needed to check that the examples in the question are supported.
+Additional checks may be required to cover all of the wording changes.
+
+!appendix
+
 !section 3.10.2(27)
 !subject Expected type of a 'Access attribute
 !reference RM95-3.10.2(27)
@@ -180,15 +281,15 @@
 !discussion
 
 > Consider the following code fragment:
-> 
+>
 >       type T is tagged null record;
 >       procedure P (X : access T);
 >       Y : aliased T'Class := ...;
-> 
+>
 >       P (Y'Access);
-> 
+>
 > Is the usage of 'Access in the procedure call legal?
-> 
+>
 > ...
 > One of the requirements applicable to the prefix is stated by RM95 3.10.2(27):
 > "If the designated type of A is tagged, then the type of the view shall be
@@ -212,17 +313,17 @@
    in a dispatching operation.
 
 So it makes sense that any access-to-T'Class value should be allowed
-as an actual parameter, as part of a dispatching call.  The only 
+as an actual parameter, as part of a dispatching call.  The only
 problem is that we don't really have a type for this value.  In some
 sense, we don't really need one, since it is about to be implicitly
-converted to the anonymous access type, but it is a little awkward 
-to talk about Y'Access without being able to point to some type 
-declaration for it.  
-
-An alternative, and probably better, way of dealing with this would 
-be to say the type of Y'Access *is* the anonymous access-to-specific type 
-of the formal access parameter "X", but add a rule to 3.9.2(7) 
-defining <class_wide_obj>'Access to be a dynamically tagged operand, 
+converted to the anonymous access type, but it is a little awkward
+to talk about Y'Access without being able to point to some type
+declaration for it.
+
+An alternative, and probably better, way of dealing with this would
+be to say the type of Y'Access *is* the anonymous access-to-specific type
+of the formal access parameter "X", but add a rule to 3.9.2(7)
+defining <class_wide_obj>'Access to be a dynamically tagged operand,
 even though its type (as determined by the expected type)
 is in fact access-to-specific, and change 3.9.2(9) to disallow this
 use unless it is in a call on a dispatching operation, and finally
@@ -233,7 +334,7 @@
 governing an actual "blah'Access" matching a formal of type "access T"
 equivalent to the rules coverning an actual "blah" matching a formal
 of type "T".  Gaining this equivalence seems like a good thing.
-    
+
 > Following this line of reasoning, the expression Y'Access above would seem
 > illegal.  But if that is the case, then how are we supposed to use access
 > parameters for dispatching?

Questions? Ask the ACAA Technical Agent