CVS difference for ais/ai-00235.txt

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

--- ais/ai-00235.txt	2000/05/17 20:49:06	1.1
+++ ais/ai-00235.txt	2000/06/01 03:31:49	1.2
@@ -1,5 +1,5 @@
-!standard 03.10.02  (02)                               00-05-09  AI95-00235/01
-!class confirmation 00-05-09
+!standard 03.10.02  (02)                               00-05-31  AI95-00235/02
+!class binding interpretation 00-05-31
 !status received 00-05-09
 !status work item 00-05-09
 !priority High
@@ -8,7 +8,8 @@
 
 !summary
 
-The expected type of 'Access (and 'Unchecked_Access) is a single access type.
+The prefix type of 'Access (and 'Unchecked_Access) can be used to resolve the
+expected access type.
 
 !question
 
@@ -26,20 +27,101 @@
 
    Value : aliased Integer := 10;
 
-   Result1 : Float := Zap (Value'access); -- Legal? (No.)
+   Result1 : Float := Zap (Value'access); -- Legal? (Yes.)
    Result2 : Float := Zap (Int_Ptr'(Value'access)); -- OK.
 
 Existing Ada 95 compilers vary widely as to whether or not they allow
 expressions like Result1's initializer.
 
-!response
+Should we allow additional flexibility here? (Yes.)
 
-The meaning of the rule 3.10.2(2) is clear, and there is no compelling reason
-to change it. Therefore, we confirm the rule.
+!recommendation
 
+(See summary.)
+
+!wording
+
+Replace 3.10.2(2) with:
+    For an attribute_reference with attribute_designator Access (or
+    Unchecked_Access -- see 13.10), the expected type shall be
+    a single access type whose designated type covers the type of
+    the prefix, or whose designated profile is type conformant
+    with that of the prefix. [The prefix of such an attribute_reference
+    is never interpreted as an implicit_dereference or parameterless
+    function_call (see 4.1.4).] The designated type or profile of the
+    expected type of the attribute_reference is the expected type or
+    profile for the prefix.
+
+!discussion
+
+A compiler survey of the most popular compilers shows that two compilers
+implement the existing RM wording reasonably closely, while four other
+compilers allow varying degrees of overloading resolution in this case.
+
+The easiest course of action would be simply to confirm the RM, and
+require the implementors to conform. However, it is clear that real Ada
+users trip over this rule periodically. It was a large Ada user that
+contacted the ACAA with the fact that compilers differ in their implementation
+of this rule, which eventually led to the creation of this AI.
+
+The user problem is most severe when an anonymous access type is involved:
+
+     function Do_It (Obj : access Integer) return Boolean;
+     function Do_It (Obj : access Float) return Boolean;
+
+     if Do_It (Value'Access) then ... -- Illegal by original RM rule.
+
+(Code like this is common in interfacing packages, where an anonymous access
+type used to implement *p parameters in functions [because In Out parameters
+are not allowed there]).
+
+To work around the problem caused by the original RM rule, a named access type
+has to be introduced, so that it can be used in a qualified expression:
+
+     if Do_It (Int_Ptr'(Value'Access)) then ... -- OK.
+
+But this is not quite equivalent, because the accessibility rules for anonymous
+access types is different from named access types. (The use of the qualified
+expression changes the accessibility check for the Access attribute from the
+anonymous type to the named type.) Thus, the user will have to declare
+an access type in the scope of each call, or will have to change to using
+'Unchecked_Access.
+
+Since some compilers allow the resolution of expressions like that in the
+question and in the example above, it is likely that real-world systems depend
+on being able to resolve these expressions. If the rule 3.10.2(2) was confirmed
+and compilers changed to conform, this existing user code would break for no
+good reason.
+
+Therefore, we adopt a liberalized rule. The new rule has to be careful to
+include the "single access type" wording, in order that 'Access not be
+allowed in type conversions or other contexts where a specific type is not
+identified.
+
+!corrigendum  3.10.02(2)
+
+@drepl
+For an @fa<attribute_reference> with @fa<attribute_designator> Access (or
+Unchecked_Access -- see 13.10), the expected type shall be
+a single access type; the @fa<prefix> of such an @fa<attribute_reference>
+is never interpreted as an @fa<implicit_dereference>. If the expected
+type is an access-to-subprogram type, then the expected profile
+of the @fa<prefix> is the designated profile of the access type.
+@dby
+For an @fa<attribute_reference> with @fa<attribute_designator> Access (or
+Unchecked_Access -- see 13.10), the expected type shall be
+a single access type whose designated type covers the type of
+the @fa<prefix>, or whose designated profile is type conformant
+with that of the @fa<prefix>. The @fa<prefix> of such an
+@fa<attribute_reference> is never interpreted as an @fa<implicit_dereference>
+or parameterless @fa<function_call> (see 4.1.4). The designated type or profile
+of the expected type of the @fa<attribute_reference> is the expected type or
+profile for the @fa<prefix>.
+
 !ACATS test
 
 ACATS test B3A2016.A, introduced in December 1999, tests this issue.
+A C-test should be created out of the example test circulated in June 2000.
 
 !appendix
 
@@ -1317,6 +1399,158 @@
 >>
 
 Well lots of AI's in the past have been language extensions (to be honest)
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, May 31, 2000 4:56 PM
+
+I sent my super-duper ACATS test for this issue to the vendors whose
+compilers I don't currently have access to to get a better feel for where
+the majority of compiler's stand.
+
+Example 1 is the basic "use-of-the-prefix-type" resolution case. (This
+should fail given the RM wording and succeed given the change proposed in
+AI-235.)
+
+Example 2 is the test of a conflict between a general access type and a
+pool-specific access type. This should fail; there is no intent to change
+this.
+
+Example 3 is the resolution of an overloaded prefix. This should fail
+(trivially) given the RM wording and succeed given the change proposed in
+AI-235.)
+
+Example 4 is similar to example 3, but it uses the type of an additional
+parameter to resolve. This should have the same results as example 3. [I
+didn't provide Examples 3&4 to all of the vendors, so not all compilers have
+results for these cases.]
+
+Here is an updated list:
+
+                            Example 1    Example 2   Example 3   Example 4
+    GNAT 3.13a:             No error     No error    Error*      Error*
+    Apex 3.0.2b:            Error        No error    Error*      Error*
+    Janus/Ada 3.1.2:        No error     Error       Error*      Error*
+    AverStar adacsrc 3.317: No error     Error       Error*      Error*
+    DDCI:                   Error        Error*
+    OcSystems 4.1:          No error     Error
+
+* Notes:
+GNAT 3.13a apparently resolves overloaded object'access prefixes by
+arbitrarily selecting the last overloaded routine as the solution. Thus some
+expressions resolve, and others do not. This seems to be a bug, it would be
+better to reject all such expressions.
+Janus/Ada 3.1.2 rejects object'access prefixes which cannot be uniquely
+resolved without context. (As I recall, allowing the use of some context for
+access-to-subprograms was very painful, but I don't know if the extension
+would be a problem.) It gets confused when object'access is overloaded with
+subprog'access.
+Apex 3.0.2b rejects object'access prefixes which cannot be uniquely resolved
+without context. It seems to prefer object'access over subprog'access when
+they both are overloaded, confusing Example 4.
+Averstar 3.317 rejects object'access prefixes which cannot be uniquely
+resolved without context. It seems to prefer subprog'access over
+object'access when they both are overloaded, confusing Example 4 (and
+exactly the reverse of Apex).
+DDCI's compiler almost matches the RM, but allows overloading between
+access-to-subprogram types and object types.
+
+----
+
+The Janus/Ada, Averstar, OcSystems, and GNAT compilers (and presumably the
+Aonix and Greenhills compilers as well) come close to Tucker's proposed
+wording. Janus/Ada and GNAT have some minor differences in handling
+overloading, and GNAT also fails the "general vs. pool-specific" issue, but
+these aren't significant.
+
+The Rational Apex and DDCI compilers come close to the existing RM wording,
+so
+they would have to change the most. But that would be painless to their
+users, while changing all of the others could very well be painful to their
+users.
+
+Note that no compilers tested handle the overloading cases properly (that
+is, as suggested by Tucker's wording).
+
+			Randy.
+
+*************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, May 31, 2000 7:43 PM
+
+A comment on part of the !discussion section:
+
+> To work around the problem caused by the original RM rule, a named access
+> type has to be introduced, so that it can be used in a qualified expression:
+>
+>      function Do_It (Obj : Int_Ptr) return Boolean;
+>
+>      if Do_It (Int_Ptr'(Value'Access)) then ... -- OK.
+>
+> But this is not quite equivalent, because the accessibility rules for
+> anonymous access types is different from named access types. Thus, the user
+> usually will have to change to using 'Unchecked_Access as well.
+
+What you say is true, but the above is a little confusing, because
+it's not necessary to change the type of the formal parameter.  The
+formal can be left as "Obj : access Integer", only the actual in
+the call needs to be changed for this workaround.  So I suggest
+deleting the function spec with the Int_Ptr parameter, and then
+you should clarify that it's the conversion implicit in the qualified
+expression that changes the accessibility semantics.  (Of course,
+as long as the extra access type is declared at the same level as
+the call, then this workaround should have the same accessibility
+semantics, i.e., no access check needed, but it's obviously a bit
+messy and error-prone to have to declare a local access type.)
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, May 31, 2000 10:27 PM
+
+> So I suggest
+> deleting the function spec with the Int_Ptr parameter,
+
+OK; I didn't realize that would work (although it obviously does).
+
+> and then you should clarify that it's the conversion implicit
+> in the qualified expression that changes the accessibility semantics.
+
+This seems as confused as my original statement. The accessibility check is
+part of the 'Access attribute (3.10.2(28-29)), and its the expected type of the
+attribute that determines the check made. Using the qualified expression
+changes the expected type to the named type, and that changes the accessibility.
+
+There is an implicit conversion to the "original" weaker checks of anonymous
+access types when the qualified expression is converted, but that won't do
+anything interesting in this case.
+
+>(Of course, as long as the extra access type is declared at the same level as
+> the call, then this workaround should have the same accessibility
+> semantics, i.e., no access check needed, but it's obviously a bit
+> messy and error-prone to have to declare a local access type.)
+
+I changed the paragraph in question to:
+
+To work around the problem caused by the original RM rule, a named access type
+has to be introduced, so that it can be used in a qualified expression:
+
+     if Do_It (Int_Ptr'(Value'Access)) then ... -- OK.
+
+But this is not quite equivalent, because the accessibility rules for anonymous
+access types is different from named access types. (The use of the qualified
+expression changes the accessibility check for the Access attribute from the
+anonymous type to the named type.) Thus, the user will have to declare
+an access type in the scope of each call, or will have to change to using
+'Unchecked_Access.
+
+
+Does that meet your concern?
+
+(Since I forgot to check it in earlier, this will be in today's version of the
+AI.)
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent