CVS difference for ai05s/ai05-0090-1.txt

--- ai05s/ai05-0090-1.txt	2008/02/05 06:33:09	1.2
+++ ai05s/ai05-0090-1.txt	2008/03/07 06:15:20	1.3
@@ -61,7 +61,7 @@
 
 !recommendation
 
-(See Summary.)
+(See summary.)
 
 !wording
 
@@ -326,5 +326,156 @@
 what we *don't* want to do, since we still want to be able to
 refer to the implicitly declared primitive using "unprefixed"
 subprogram call notation.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, February  6, 2008  12:11 AM
+
+> > ... Another possibility would be
+> > to try and make certain declarations illegal, but that isn't appealing
+> > either, as it would introduce illegalities for no particularly good
+> > reason (plus it wouldn't work for technical reasons).
+> 
+> Can you explain these "technical reasons"?
+> We make it illegal to have an entry or
+> protected subprogram that is homographic with the
+> prefixed view of an explicit overriding.  Why can't we
+> do the same for an explicit non-overriding primitive?
+
+You're right, we could do that, and I started off by doing that.
+But there are other cases that that have a similar effect where
+the conflicting operation isn't a primitive, such as a class-wide
+subprogram:
+
+  procedure Other_Op (T : Synchronized_Type'Class);
+
+Do we want to disallow that as well?  I'm assuming we don't.
+
+At the time it had seemed to me to be needlessly restrictive to
+disallow any of these cases.  After all, an implementation can
+always issue a warning that certain calls will be ambiguous.  I was
+thinking that a user might have some reason to declare an explicit
+primitive that conflicts, and have a homographic task entry that
+can still be called from within the task even though it can't be
+called from outside.  But I'm willing to admit that that's a stretch,
+and probably isn't an idiom worth allowing, so if the feeling is that
+such a conflict with a primitive almost certainly indicates an error,
+then I'm willing to go along with making the case of a primitive
+illegal.
+
+> > ...
+> > Clearly we need a change to effectively give preference to one of the
+> > two operations.  The proposed fix is to prefer the interpretation of
+> > the entry (or protected subprogram), and to consider the implicit
+> > overriding operation effectively hidden at the point of a selector_name
+> > in a prefixed call.  It seems somewhat more natural to prefer the entry
+> > or protected subprogram over the implicit overriding subprogram since
+> > the former is explicit in the program text (though formulating the
+> > rule the other way could also be considered).
+>
+> I strongly prefer having the entry/protected subprogram
+> visible via prefixed notation.  That is what you would
+> get in the absence of the interface, and it seems weird
+> that the formal parameter names, defaults, etc., would
+> suddenly change just because the task type now implements
+> an interface.  So I agree with your current solution, and
+> would be opposed to the alternate you considered.
+
+For some reason I was wavering, then ended up leaning towards
+the recommended preference, but hadn't fully solidified my commitment
+to that by the time I wrote it up, even though it felt right to me
+based on wanting to get the formal names, etc.  However, your comment
+has convinced me that it's the right choice. :-)  (I was a little
+worried that some semantic glitch might pop up that would argue for
+preferring the other, so wanted to leave the option open, but that was
+most probably just FUD.)
+
+> > ...In terms of the rules,
+> > this is implemented by making the implicit overriding subprogram
+> > hidden from all visibility at the point of a selector_name in cases
+> > that would otherwise be ambiguous.
+> 
+> Do we really need to use the term "hidden from all visibility" here?
+> I think all you need to do is have 4.1.3(9.2) include a rule
+> that disallows referring to a primitive subprogram that is implemented
+> by an entry or protected subprogram.  Remember that 4.1.3(9.2)
+> is all considered "Name Resolution" so disallowing something is
+> effectively creating an overload resolution rule.  Hiding from
+> "all visibility" seems like overkill, and is probably exactly
+> what we *don't* want to do, since we still want to be able to
+> refer to the implicitly declared primitive using "unprefixed"
+> subprogram call notation.
+
+I defined it as hidden only within the specific context of the
+selector_name, not hidden in general, so that it wouldn't affect
+normal calls, but I admit that's an unorthodox use of "hidden from
+all visibility".  Anyway, I'm fine with going the route of adding
+a rule in 4.1.3 to cover this case, and will try to draft some
+wording for that.
+
+BTW, in your comment above you say "disallows referring to a primitive
+subprogram that is implemented by...", but is that really what we
+want?  That would disallow dispatching calls using prefixed notation.
+My attempted fix was written to hide the implicit primitive only for
+calls that could be made to the entry itself, that is, calls where
+the prefix is of the specific type, but to still allow calls with
+class-wide prefixes to be made to the dispatching primitive.
+
+It seems unfortunate to lose the dispatching calls, though obviously
+those would still be possible using normal call notation, just not with
+prefixed notation.  Wouldn't it be preferable to try and formulate the
+rule so as to also permit dispatching calls that use prefixed notation?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February  6, 2008  5:30 AM
+
+> You're right, we could do that, and I started off by doing that.
+> But there are other cases that that have a similar effect where
+> the conflicting operation isn't a primitive, such as a class-wide
+> subprogram:
+> 
+>   procedure Other_Op (T : Synchronized_Type'Class);
+> 
+> Do we want to disallow that as well?  I'm assuming we don't.
+
+These aren't homographs, so trying to make these illegal
+is probably more trouble than it is worth.  But that doesn't
+change my mind about disallowing the more common case of
+a homographic primitive.
+> 
+> At the time it had seemed to me to be needlessly restrictive to
+> disallow any of these cases.  After all, an implementation can
+> always issue a warning that certain calls will be ambiguous.  I was
+> thinking that a user might have some reason to declare an explicit
+> primitive that conflicts, and have a homographic task entry that
+> can still be called from within the task even though it can't be
+> called from outside.  But I'm willing to admit that that's a stretch,
+> and probably isn't an idiom worth allowing, so if the feeling is that
+> such a conflict with a primitive almost certainly indicates an error,
+> then I'm willing to go along with making the case of a primitive
+> illegal.
+
+I think that is more consistent.  It seems weird that it is illegal
+to have a homographic overriding, but it is OK to have a homographic
+operation that does *not* override an inherited primitive.  I don't
+think you are doing the user any favors by having this distinction.
+
+...
+> It seems unfortunate to lose the dispatching calls, though obviously
+> those would still be possible using normal call notation, just not with
+> prefixed notation.  Wouldn't it be preferable to try and formulate the
+> rule so as to also permit dispatching calls that use prefixed notation?
+
+I'm not sure what you mean by "losing" dispatching calls.
+If I have a prefix of task_type'Class, I still have visibility
+on the entries of task_type I hope!  I just don't need to
+do any "dispatching" to know which entry, since you can't
+further extend a concrete task type.  This is similar to referring
+to the components of a record type when the prefix of the
+selected component is record_type'Class.  No dispatching is
+involved.
 
 ****************************************************************