CVS difference for ai12s/ai12-0140-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0140-1.txt

--- ai12s/ai12-0140-1.txt	2014/10/14 03:43:43	1.1
+++ ai12s/ai12-0140-1.txt	2014/10/14 03:50:40	1.2
@@ -1,4 +1,5 @@
-!standard 13.1.1(34/3)                                  14-10-13  AI05-0140-1/01
+!standard 3.4(7/3)                                 14-10-13  AI05-0140-1/01
+!standard 3.4(8/2)
 !class binding interpretation 14-10-13
 !status work item 14-10-13
 !status received 14-07-10
@@ -83,6 +84,9 @@
 like this, but the constrainedness of a type is not a "characteristic"
 (which are listed in 3.4).
 
+(6) One could imagine just declaring that a partial view statically matches
+the corresponding full view, but that might have issues of its own. (Such
+as how far we go with subtypes.)
 
 !ASIS
 
@@ -141,108 +145,163 @@
 From: Tucker Taft
 Sent: Friday, July 11, 2014  9:26 AM
 
-Your code is legal.  Janus seems to be freezing the fact that the designated type of My_String_Access is unconstrained, rather than recomputing it based on visibility at the point of generic instantiation.  The rule for static matching between the designa
ted subtype of a formal and actual has nothing to do with where the access type is declared.
+Your code is legal.  Janus seems to be freezing the fact that the designated
+type of My_String_Access is unconstrained, rather than recomputing it based on
+visibility at the point of generic instantiation.  The rule for static matching
+between the designated subtype of a formal and actual has nothing to do with
+where the access type is declared.
 
 ****************************************************************
 
 From: Randy Brukardt
 Sent: Monday, July 14, 2014  6:54 PM
 
-You don't give any justification for this position. I couldn't find any in the RM. I wouldn't expect a property of an access type to change over its life without some explicit wording for that.
+You don't give any justification for this position. I couldn't find any in the
+RM. I wouldn't expect a property of an access type to change over its life
+without some explicit wording for that.
+
+For a counter-example, access-to-incomplete types are always considered that
+during their full lifetime - that does not change because of visibility. We have
+special rules that say that they are treated as complete when the completion of
+the incomplete type is available. (See 3.10.1(2.2/2-2.6/3)).
+
+We've got rules defining that characteristics behave this way, but whether a
+type is constrained or not does not appear to be a characteristic -- at least
+its not mentioned in the list in 3.4(8/2).
+
+So I don't see any RM reason for your interpretation. Perhaps there is a
+usability one (although I think it would have to be fairly strong given the
+destruction of the model that types are defined by their definition, which we
+adhere to despite the often nonsense results that one gets).
 
-For a counter-example, access-to-incomplete types are always considered that during their full lifetime - that does not change because of visibility. We have special rules that say that they are treated as complete when the completion of the incomplete ty
pe is available. (See 3.10.1(2.2/2-2.6/3)).
-
-We've got rules defining that characteristics behave this way, but whether a type is constrained or not does not appear to be a characteristic -- at least its not mentioned in the list in 3.4(8/2).
-
-So I don't see any RM reason for your interpretation. Perhaps there is a usability one (although I think it would have to be fairly strong given the destruction of the model that types are defined by their definition, which we adhere to despite the often 
nonsense results that one gets).
-
 ****************************************************************
 
 From: Tucker Taft
 Sent: Monday, July 14, 2014  7:40 PM
 
->> Your code is legal.  Janus seems to be freezing the fact that the 
->> designated type of My_String_Access is unconstrained, rather than 
->> recomputing it based on visibility at the point of generic 
->> instantiation.  The rule for static matching between the designated 
->> subtype of a formal and actual has nothing to do with where the 
+>> Your code is legal.  Janus seems to be freezing the fact that the
+>> designated type of My_String_Access is unconstrained, rather than
+>> recomputing it based on visibility at the point of generic
+>> instantiation.  The rule for static matching between the designated
+>> subtype of a formal and actual has nothing to do with where the
 >> access type is declared.
 >
-> You don't give any justification for this position. I couldn't find 
-> any in the RM. I wouldn't expect a property of an access type to 
+> You don't give any justification for this position. I couldn't find
+> any in the RM. I wouldn't expect a property of an access type to
 > change over its life without some explicit wording for that.
-
-But this is not a property of the access type, it is a property of the designated type. 
-Furthermore, these are exactly the *same* type, so it is downright weird if they don't match each other statically.  If you want other analogies, the properties of a composite type change when more information is learned about the component type.  See 7.3
(3/3).  But my main claim is that this is not a property of the access type at all.  It is a property of the designated type, and you can use whatever you know about the designated type, even if it is "more" than is known where the access type is declared.

 
-You mention access-to-incomplete -- that seems a perfect example of this.  Anywhere you can see the completion of the incomplete type, you can use that information, no matter where the access-to-incomplete type is declared.  Yes we have extra wording to t
hat effect in 3.10.1(2.4), but that wording is not saying anything profound.  We just had to be careful because of the oddities associated with limited with's.  There are no such subtleties for other properties relating to designated types.
-
-> For a counter-example, access-to-incomplete types are always 
-> considered that during their full lifetime - that does not change 
-> because of visibility. We have special rules that say that they are 
+But this is not a property of the access type, it is a property of the
+designated type. Furthermore, these are exactly the *same* type, so it is
+downright weird if they don't match each other statically.  If you want other
+analogies, the properties of a composite type change when more information is
+learned about the component type.  See 7.3(3/3).  But my main claim is that this
+is not a property of the access type at all.  It is a property of the designated
+type, and you can use whatever you know about the designated type, even if it is
+"more" than is known where the access type is declared.
+
+You mention access-to-incomplete -- that seems a perfect example of this.
+Anywhere you can see the completion of the incomplete type, you can use that
+information, no matter where the access-to-incomplete type is declared.  Yes we
+have extra wording to that effect in 3.10.1(2.4), but that wording is not saying
+anything profound.  We just had to be careful because of the oddities associated
+with limited with's.  There are no such subtleties for other properties relating
+to designated types.
+
+> For a counter-example, access-to-incomplete types are always
+> considered that during their full lifetime - that does not change
+> because of visibility. We have special rules that say that they are
 > treated as complete when the completion of the incomplete type is available. (See 3.10.1(2.2/2-2.6/3)).
 >
-> We've got rules defining that characteristics behave this way, but 
-> whether a type is constrained or not does not appear to be a 
+> We've got rules defining that characteristics behave this way, but
+> whether a type is constrained or not does not appear to be a
 > characteristic -- at least its not mentioned in the list in 3.4(8/2).
 >
-> So I don't see any RM reason for your interpretation. Perhaps there is 
-> a usability one (although I think it would have to be fairly strong 
-> given the destruction of the model that types are defined by their 
+> So I don't see any RM reason for your interpretation. Perhaps there is
+> a usability one (although I think it would have to be fairly strong
+> given the destruction of the model that types are defined by their
 > definition, which we adhere to despite the often nonsense results that one gets).
 
-Well it sounds like an AI would be helpful to clarify this, but for me you are inappropriately associating a property of the designated type with the access type.  The properties of the designated type change as you learn more about the designated type.  
The particular access type involved is somewhat irrelevant, as far as I am concerned, and especially as far as static matching is concerned.
+Well it sounds like an AI would be helpful to clarify this, but for me you are
+inappropriately associating a property of the designated type with the access
+type.  The properties of the designated type change as you learn more about the
+designated type.  The particular access type involved is somewhat irrelevant, as
+far as I am concerned, and especially as far as static matching is concerned.
 
 ****************************************************************
 
 From: Randy Brukardt
 Sent: Monday, July 14, 2014  8:29 PM
 
-> But this is not a property of the access type, it is a property of the 
+> But this is not a property of the access type, it is a property of the
 > designated type.
-> Furthermore, these are exactly the *same* type, so it is downright 
+> Furthermore, these are exactly the *same* type, so it is downright
 > weird if they don't match each other statically.
+
+They're the same type but different views of that type. They don't necessarily
+have to match (certainly different subtypes of a type don't have to match). But
+I do agree that a user would find it weird if they didn't match (this I hadn't
+previously noticed).
 
-They're the same type but different views of that type. They don't necessarily have to match (certainly different subtypes of a type don't have to match). But I do agree that a user would find it weird if they didn't match (this I hadn't previously notice
d).
-  
-> If you want other analogies, the properties of a composite type change 
-> when more information is learned about the component type.  See 
+> If you want other analogies, the properties of a composite type change
+> when more information is learned about the component type.  See
 > 7.3(3/3).
 
 Um, that's the syntax for a private extension.
 
-You probably meant 7.3.1(3/3), which is of course the "characteristics" rule that I referred to. The problem being that whether or not a type is constrained doesn't appear to be a "characteristic" (these are defined in 3.4(8/2). Perhaps it should be.
+You probably meant 7.3.1(3/3), which is of course the "characteristics" rule
+that I referred to. The problem being that whether or not a type is constrained
+doesn't appear to be a "characteristic" (these are defined in 3.4(8/2). Perhaps
+it should be.
 
 > But my main claim is that
-> this is not a property of the access type at all.  It is a property of 
-> the designated type, and you can use whatever you know about the 
-> designated type, even if it is "more" than is known where the access 
+> this is not a property of the access type at all.  It is a property of
+> the designated type, and you can use whatever you know about the
+> designated type, even if it is "more" than is known where the access
 > type is declared.
 
-Even if it is, it doesn't appear to be a "characteristic" that appears when you have more visibility.
- 
-> You mention access-to-incomplete -- that seems a perfect example of 
-> this.  Anywhere you can see the completion of the incomplete type, you 
-> can use that information, no matter where the access-to-incomplete 
-> type is declared.  Yes we have extra wording to that effect in 
-> 3.10.1(2.4), but that wording is not saying anything profound.  We 
-> just had to be careful because of the oddities associated with limited 
+Even if it is, it doesn't appear to be a "characteristic" that appears when you
+have more visibility.
+
+> You mention access-to-incomplete -- that seems a perfect example of
+> this.  Anywhere you can see the completion of the incomplete type, you
+> can use that information, no matter where the access-to-incomplete
+> type is declared.  Yes we have extra wording to that effect in
+> 3.10.1(2.4), but that wording is not saying anything profound.  We
+> just had to be careful because of the oddities associated with limited
 > with's.
-> There are no such subtleties for other properties relating to 
+> There are no such subtleties for other properties relating to
 > designated types.
 
-Harmph. You seem to have conveniently forgotten about all of the problems with "additional characteristics", especially in generics. I'd say there's a pile of subtleties for other properties (including which properties are in fact included). I know there'
s quite a pile of ACATS tests on these weird cases (and I'd probably be strung up by implementers if I created any more :-).
+Harmph. You seem to have conveniently forgotten about all of the problems with
+"additional characteristics", especially in generics. I'd say there's a pile of
+subtleties for other properties (including which properties are in fact
+included). I know there's quite a pile of ACATS tests on these weird cases (and
+I'd probably be strung up by implementers if I created any more :-).
 
 ...
-> Well it sounds like an AI would be helpful to clarify this, but for me 
-> you are inappropriately associating a property of the designated type 
-> with the access type.  The properties of the designated type change as 
-> you learn more about the designated type.  The particular access type 
-> involved is somewhat irrelevant, as far as I am concerned, and 
+> Well it sounds like an AI would be helpful to clarify this, but for me
+> you are inappropriately associating a property of the designated type
+> with the access type.  The properties of the designated type change as
+> you learn more about the designated type.  The particular access type
+> involved is somewhat irrelevant, as far as I am concerned, and
 > especially as far as static matching is concerned.
-
-It's pretty clear to me that we're statically matching the private view (which is what the access type designates) to the full view (which is what the generic has for an actual). The view designated by an access type never changes! The question is whether
 the "characteristics" (the only things that rely on visibility) include everything needed for static matching. It's certainly true that the private view has more characteristics at the point of this instance than it does at the point of the declaration of
 the access type, but does it have enough for static matching? Static matching is quite a bit tougher than simple type matching, after all.
 
-We could simply say that they statically match, but that seems dangerous if there is any way for a visibility hole to be involved (that is, a case where both the partial and full views are visible but the relationship between them is not visible). [I can'
t think of one off-hand, but there are so many ways to create those that I can't convince myself that it is impossible.] And of course we'd have to be careful that other subtypes don't get sucked into such a special rule.
+It's pretty clear to me that we're statically matching the private view (which
+is what the access type designates) to the full view (which is what the generic
+has for an actual). The view designated by an access type never changes! The
+question is whether the "characteristics" (the only things that rely on
+visibility) include everything needed for static matching. It's certainly true
+that the private view has more characteristics at the point of this instance
+than it does at the point of the declaration of the access type, but does it
+have enough for static matching? Static matching is quite a bit tougher than
+simple type matching, after all.
+
+We could simply say that they statically match, but that seems dangerous if
+there is any way for a visibility hole to be involved (that is, a case where
+both the partial and full views are visible but the relationship between them is
+not visible). [I can't think of one off-hand, but there are so many ways to
+create those that I can't convince myself that it is impossible.] And of course
+we'd have to be careful that other subtypes don't get sucked into such a special
+rule.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent