CVS difference for ai05s/ai05-0149-1.txt
--- ai05s/ai05-0149-1.txt 2009/04/30 06:07:22 1.1
+++ ai05s/ai05-0149-1.txt 2009/05/19 22:41:01 1.2
@@ -1,11 +1,13 @@
-!standard 4.5.2(3/2) 09-04-29 AI05-0149-1/02
+!standard 4.5.2(3/2) 09-05-19 AI05-0149-1/02
!standard 4.5.2(30.2/2)
+!standard 3.10.1(2/2)
+!standard 8.6(25/2)
!class Amendment 09-04-12
!status work item 09-04-12
!status received 09-04-12
!priority Medium
!difficulty Medium
-!subject Access type membership
+!subject Access types and conversion, membership, and limited with
!summary
@@ -19,13 +21,69 @@
conversion to check if the conversion will succeed, but the current
rules for access-type membership tests don't allow for this.
+The limited with clause makes incomplete views of types visible.
+Tagged incomplete types are useful for formal parameters, but
+most other incomplete types are pretty much useless, except
+as the designated type of an access type. It would be nice
+if a named access type declared in a package named in a limited with
+clause could be used somehow, if only as a parameter type.
+
+If the named (incomplete) access type cannot be used directly,
+then it might be 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 anonymous access type
+to a named access type were implicit.
+
+Finally, there seems no reason to require an explicit conversion
+to a named access-to-classwide type that is certain to succeed the
+tag check (i.e., is a "widening" conversion). This will reduce
+the need for anonymous access types in general, which is considered
+probably a good thing.
+
!proposal
+
+This AI makes four related proposals:
-When the tested type of a membership test is a general access
-type, allow the expression to be of an anonymous access type.
+1) When the tested type of a membership test is a general access
+ type, allow the expression to be of an anonymous access type.
+
+2) Incomplete access types, which are access types declared in a
+ limited view of a package, may be used as formal parameter and result
+ types.
+
+3) Implicit conversion is provided from an anonymous access type
+ with a static accessibility level to a named, general access type,
+ provided the explicit conversion is legal (i.e. static accessibility
+ check passes; designated types match if untagged); further, if the
+ 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).
+
+4) Implicit conversion is provided from a named access type with a static
+ accessibility level to a named, general access-to-classwide type,
+ provided the designated type of the target access type covers that of
+ the source type. The usual static accessibility level check applies.
+
+
+*Incomplete access types* are created as part of a limited view of a
+package. Each non-derived access type declared in the visible part of a
+package spec becomes an incomplete access type in the limited view.
+Derived access types don't become incomplete access types in the limited
+view because they aren't syntactically distinguishable from any other
+kind of untagged derived type.
+
+Incomplete named access types may *not* be used for components.
+Instead, anonymous access types may be used for those, and then the
+anonymous access type may be implicitly converted to the named access
+type in places with a full view of the named access type.
+
!wording
+Wording for parts (2), (3), and (4) is TBD. For part (1):
+
Modify 4.5.2(3/2) as follows:
The tested type of a membership test is the type of the range or the
@@ -49,8 +107,15 @@
simple_expression is covered by the designated type of the tested type.
!discussion
+
+We have grouped part (1) with these other proposals as any
+changes to the implicit conversion rules will affect the name
+resolution rules for membership. Hence, we anticipate the wording
+proposed above for (1) to be refined further when we finalize the
+wording for (3) and (4), and hence having separate AIs will just
+create integration headaches.
-The basic goal is that membership will return false if an attempt
+The basic goal of (1) is that membership will return false if an attempt
to convert the simple_expression into the tested type will be
illegal or fail a run-time check.
@@ -75,6 +140,109 @@
But this seems like a simple improvement that handles many of the
interesting cases of run-time accessibility checks.
+Proposal part (2) addresses a concern that a "limited with" naming a package
+with named access types forces the use of a lot of explicit conversion
+and/or anonymous access types in the clients.
+
+We are proposing to allow "incomplete access types" (not to be confused
+with "incomplete types whose full type is an access type" ;-) to be used
+as formal parameter and result types, analogous to tagged incomplete
+types, as well as providing some additional implicit conversions from
+anonymous access types to named access types.
+
+The third part of this proposal addresses the implicit conversion of
+anonymous access types to named access types for everything *but*
+parameters. For parameters, the first part of this proposal 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. Using anonymous access types for formal parameters
+introduces additional dynamic accessibility checks, whereas using the
+named access type directly avoids that.
+
+The fourth part of this proposal provides the same level of implicit
+conversion for access-to-classwide types as is provided for classwide
+types directly. This part has more upward compatilibity issues, so
+will require additional evaluation.
+
+IMPLEMENTATION CONCERNS:
+
+An incomplete access type is OK as a parameter or result since
+access-type parameters and results are always passed by copy, and
+the implementation can use a default general-access-type representation
+for them, even if the full named access type turns out to have some kind
+of aspect clause. This is in contrast to the case with components,
+where an aspect clause would need to be obeyed to ensure streaming,
+aliased objects, etc., work as expected.
+
+Note that we have chosen to allow incomplete access types as function
+results, even though we restricted tagged incomplete types to being
+parameters. Tagged incomplete type results introduces a number of
+tricky issues that are not present for incomplete access types, so there
+seems no reason to restrict incomplete access types from being result
+types.
+
+For implicit conversion, we are only allowing it when the accessibility
+check is known to succeed statically. Since an explicit conversion is
+always available, there seems no reason to hide conversions that might
+in fact fail. Similarly, we are disallowing implicit "narrowing"
+conversions, which might fail a tag check. For example, if "type NT is
+new T with ..." we are disallowing an implicit conversion from anon
+acc-to-T'class to a named acc-to-NT'class, since there is a possibility
+that it will fail the tag check. Again, an explicit conversion is more
+appropriate here.
+
+COMPATIBILITY CONCERNS:
+
+Introducing additional implicit conversions *from* anonymous access types
+and/or *to* named access-to-classwide types could introduce some
+ambiguity into existing programs. For the conversions *from* an anonymous
+access type, this seems like a relatively small
+price to pay, as the ambiguity would occur under limited circumstances:
+the actual parameter is of an anonymous access type, and there are two
+functions with the same name differing only in that one has an access
+parameter where the other has a parameter of a named access type. Such
+a pair of functions would be ambiguous if the actual parameter were of the
+named access type, so it doesn't seem unreasonable that they would
+also end up ambiguous if the actual were of an anonymous type.
+
+For the conversion *to* a named access-to-classwide type, this is perhaps
+more of a concern, as currently two subprograms that differ in the named
+access type of a parameter are not ambiguous unless the actual 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 (3) and (4), though more so to (4), as
+existing code could never pass an anonymous access type to a formal
+that is of a named access type.
+
+QUESTIONS:
+
+Q: Might a special "type T is access;" syntax be worthwhile? Perhaps it could
+be a way to indicate in a limited view that a derived type
+is in fact an access type. E.g.:
+
+ type NT is access;
+ type NT is new T;
+
+And in general it would be a way to allow the incomplete type
+to be used as a formal parameter/result type before the full type
+definition is provided.
+
+We have not proposed this syntax for now, as the need does not seem compelling.
+However, it could be added to this proposal, now or at a later date.
+
+ASIDE: Hmmm... I wonder whether we could have generic formal incomplete
+types as a way to allow instantiation with a private type before
+it is fully defined. This might be sufficient for a "signature"
+generic. End of ASIDE.
+
+Q: Should the calling convention of a subprogram with an
+incomplete access type formal be automatically intrinsic, or should
+we presume that implementations can deal with this issue under the
+covers if necessary? I'd vote for the latter, since in 90%
+of the cases nothing special would be required, and in the
+few cases where something special is required, the implementation
+can always create a wrapper.
+
!example
@@ -456,3 +624,135 @@
****************************************************************
+From: Tucker Taft
+Sent: Thursday, April 30, 2009 1:34 AM
+
+I didn't see the need for membership tests between two different named access types.
+We don't have that for numeric types, even though conversions are allowed between then,
+and it felt weird to me to extend membership tests in that way. Tagged types are
+different, in that there is a well-defined hierarchy, and conversion up and down the
+hierarchy serves a different purpose than other kinds of conversions.
+
+I did realize after writing up this new version that the original version allowed
+membership tests across distinct named access types, but that seemed undesirable once
+I realized it.
+
+I suppose another reason to disallow membership tests across distinct named access types
+is that it introduces more incompatibility due to added ambiguity.
+
+Anyway, there are some reasons. I'm not hard over on it, and I suppose membership tests
+between two named access-to-tagged types might make some sense. Membership tests between
+two named access-to-untagged seems pretty hard to justify.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April 30, 2009 1:48 AM
+
+> I did realize after writing up this new version that the original
+> version allowed membership tests across distinct named access types,
+> but that seemed undesirable once I realized it.
+
+Humm, I thought it was a feature. And you described as one in your old writeup, that
+why I noticed it was gone.
+
+As I mentioned later, it seems useful in a generic body to see if converting to a
+global type or a formal access type is possible (that would depend on where you are
+instantiated). Not an important need though.
+
+> I suppose another reason to disallow membership tests across distinct
+> named access types is that it introduces more incompatibility due to
+> added ambiguity.
+
+Huh? What ambiguity could occur? Is there any useful membership allowed now (I
+thought all you could do is test an object against its type, getting True; I doubt
+there is much of that in programs!)
+
+> Anyway, there are some reasons. I'm not hard over on it, and I
+> suppose membership tests between two named access-to-tagged types
+> might make some sense. Membership tests between two named
+> access-to-untagged seems pretty hard to justify.
+
+Well, I tried above. You can take it or leave it - this isn't an important issue,
+just surprising to me.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, April 30, 2009 12:50 PM
+
+> I didn't see the need for membership tests between two different named
+> access types.
+
+I agree with Tuck on this issue.
+
+Still, it seems like the wording to express this idea would be simpler if
+the word "convertible" were used in place of something like "whose designated
+type is the same as that of the tested type, or if tagged, convertible to the
+designated type of the tested type".
+
+Can't we make use of the existing definition of "convertible"
+in much the same way as is already done in the tagged case?
+Something like
+ If the tested type is a general access-to-object type, then the
+ simple_expression shall resolve to be of the tested type or of
+ an anonymous type that is convertible to the the tested
+ type.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, April 30, 2009 1:16 PM
+
+I tried to explain why I dropped that albeit simpler wording in the !discussion
+section. The problem is that we don't normally expect the overload resolution
+algorithm to deal with things as subtle as access-type convertibility.
+
+In the case of access types, convertibility includes things like static matching
+of designated subtypes, and static accessibility level comparisons. Those would
+be new things for overload resolution to worry about. By contrast, the wording
+I propose, though more complicated, is actually a pretty good match to existing
+resolution rules between anonymous access types and named access types.
+
+Interestingly, if we combine this with the other AI relating to "limited with
+and access types," where we are proposing to allow implicit conversion *from*
+anonymous access types *to* named access types in more contexts, this may simplify
+again, back to something like normal expected-type resolution (though there might
+be an added legality rule that would *not* apply to membership tests but *would*
+apply in other "implicit conversion" contexts).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, May 19, 2009 12:12 PM
+
+Here is a very straightforward combination of ai-149 and ai-151, plus I added in
+Bob's proposal that we allow implicit conversions to a named access-to-classwide
+type from other *named* access types covered by it. That is part (4) of this
+4-part AI (not sure whether we have achieved 4-part harmony ;-).
+
+[Ed: This is version /04 of this AI.]
+
+I doubt I will have a chance to do much more with this AI before tomorrow.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, May 19, 2009 3:05 PM
+
+> Here is a very straightforward combination of ai-149 and ai-151,
+
+Looks good.
+
+> plus I added in Bob's proposal that we allow implicit conversions to a
+> named access-to-classwide type from other
+> *named* access types covered by it.
+
+Thanks! That's the key feature.
+
+>...That is part (4) of this
+> 4-part AI (not sure whether we have achieved 4-part harmony ;-).
+
+;-)
+
+****************************************************************
Questions? Ask the ACAA Technical Agent