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

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

--- ai12s/ai12-0140-1.txt	2015/07/09 01:04:37	1.5
+++ ai12s/ai12-0140-1.txt	2015/07/14 02:29:41	1.6
@@ -476,3 +476,88 @@
 a problem there (it could be FUD).
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, July 8, 2015  8:09 PM
+
+> I think this would make more sense if it talked about the "view of the 
+> designated subtype", since the designated subtype itself is surely 
+> determined solely by the declaration (as defined in 3.10(10)). And it 
+> seems to be a tautology that the designated subtype is determined by 
+> the view of the designated subtype (duh!), which is what it currently 
+> says. Maybe it would be better to start:
+>
+>     The view of the designated subtype of (a view of) an access type 
+>     at a given point is the view of the designated
+>     subtype that is visible at that point, except in the case ...
+
+Yes, that seems like a useful fix.
+
+> I think we have to be clearer than "visible at that point"; I'm not 
+> sure what kind of visibility you're talking about here.
+
+I don't see the ambiguity.  When you say "visible at a point" (or place)
+that means exactly one thing, which is defined in in 8.3(14), saying that
+"a declaration is visible everywhere within its scope, except where hidden
+from *all* visibility."
+
+> I'd also worry that this sort of rule would introduce a ripple effect 
+> (after all, the reason that we have the complex incomplete rules is to 
+> avoid a ripple effect). Since this is intended to fix issues with 
+> static matching (coming from confusion about what view an access type 
+> uses), one could potentially get a ripple effect anywhere that static 
+> matching is required on a designated partial view. When we get a full 
+> proposal for this wording, I'll try to see if there is a problem there (it could be FUD).
+
+I don't believe this should be a concern.  It is only the
+incomplete-in-limited-view types that are affected by the presence of
+"with" clauses (and hence susceptible to "ripple" effects), and we make a
+special exception for those.  All others require being inside the scope of the
+full type to have any additional visibility.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, July 8, 2015  8:52 PM
+
+...
+> > I think we have to be clearer than "visible at that point"; I'm not 
+> > sure what kind of visibility you're talking about here.
+> 
+> I don't see the ambiguity.  When you say "visible at a point" 
+> (or place) that means exactly one thing, which is defined in 
+> in 8.3(14), saying that "a declaration is visible everywhere 
+> within its scope, except where hidden from *all* visibility."
+
+Whenever I read "visible", I think "directly visible". And then spend some time
+wondering if that was meant or something else. It's unfortunate that there's
+no prefix for the 8.3(14) meaning of "visible", because it's not the intuitive
+meaning of "visible". But I agree its consistent with the RM wording, so it's
+probably just me that is confused (every time, even though I've been doing this
+for decades and vaguely know that it doesn't mean what it seems to mean).
+
+> > I'd also worry that this sort of rule would introduce a ripple effect 
+> > (after all, the reason that we have the complex incomplete rules is to 
+> > avoid a ripple effect). Since this is intended to fix issues with 
+> > static matching (coming from confusion about what view an access type 
+> > uses), one could potentially get a ripple effect anywhere that static 
+> > matching is required on a designated partial view. When we get a full 
+> > proposal for this wording, I'll try to see if there is a problem there (it
+> > could be FUD).
+> 
+> I don't believe this should be a concern.  It is only the 
+> incomplete-in-limited-view types that are affected by the 
+> presence of "with" clauses (and hence susceptible to "ripple" 
+> effects), and we make a special exception for those.  All 
+> others require being inside the scope of the full type to 
+> have any additional visibility.
+
+You might be right. My thought was that the "scope" of something includes units
+where it is "withed", so there is potential for trouble (especially if
+something is exported and then imported back into the subsystem). But I'll have
+to work out an example to know one way or another, and since my budget for this
+FY is exhausted, I'll do that once I get a new budget. (I'm only doing critical
+tasks -- mainly the meeting minutes -- now.)
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent