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

Differences between 1.8 and version 1.9
Log of other versions for file ai05s/ai05-0125-1.txt

--- ai05s/ai05-0125-1.txt	2011/02/10 05:40:42	1.8
+++ ai05s/ai05-0125-1.txt	2011/02/16 06:15:22	1.9
@@ -468,3 +468,358 @@
 Perhaps that won't be a problem in the actual AARM.
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 10, 2011  8:02 AM
+
+> I found the new AARM note midly confusing, since it seems to apply to
+> both of the new paragraphs, but it is really only talking about the
+> second one. I was trying to figure how it worked in the "normal" case
+> and it didn't make much sense.
+
+Actually the first paragraph of the AARM note applies only to the second
+paragraph, while the second paragraph of the AARM note applies to both!
+Probably should somehow make that a little clearer...
+
+> Perhaps that won't be a problem in the actual AARM.
+
+Perhaps a little clever formatting, or adding some wording to identify which
+normative paragraphs each AARM note applies to.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, February 10, 2011  4:27 PM
+
+I have some corner-case questions about how this one interacts with interface
+types.
+
+In the first paragraph of the proposed wording , it says
+
+     ... so long as a corresponding dispatching operation of some
+     ancestor type is visible ....
+
+Consider the following variation on the example given in the AI:
+
+     package A1 is
+        type Base is abstract tagged private;
+        procedure P1 (X : Base);
+     private
+        type Base is tagged null record;
+        procedure P2 (X : Base);
+     end A1;
+
+     package A1.A2 is
+        type Child is new Base with private;
+        procedure P1 (X : Child);
+     private
+        type Child is new Base with null record;
+        procedure P2 (X : Child);
+     end A1.A2;
+
+     package Some_Other_Pkg is
+        type Ifc is interface;
+        procedure P2 (X : Ifc) is abstract;
+     end Some_Other_Pkg;
+
+     with A1.A2;
+     with Some_Other_Pkg;
+     package Foo is
+        type Grandchild is new A1.A2.Child and Some_Other_Pkg.Ifc with private;
+        procedure P1 (X : Grandchild);
+     private
+        type Grandchild is new A1.A2.Child and Some_Other_Pkg.Ifc
+          with null record;
+        procedure P2 (X : Grandchild);
+     end Foo;
+
+We replaced A1.A3 with Foo, so we lose all visibility there into A1's private
+part. One might think that this would mean that the the new wording no longer
+applies, but we have this interface type IFc which is a progenitor of Grandchild
+and has a P2 with the right profile. So does the wording apply? Does this mean
+that the AI introduces unwanted overriding? Or does the word "corresponding" (in
+the cited RM wording) *obviously* eliminate the problem.
+
+Perhaps there is no problem here, but it seems that we might want an AARM note
+to clarify this situation.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 10, 2011  8:06 PM
+
+I think the intent is pretty clear, but an AARM note could be used to minimize
+the chance of an "unfriendly" reading.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 10, 2011  9:52 PM
+
+> I think the intent is pretty clear, but an AARM note could be used to
+> minimize the chance of an "unfriendly"
+> reading.
+
+I've lost track of what the intent IS. Perhaps one of you can help out??
+
+...
+> Steve Baird wrote:
+> > I have some corner-case questions about how this one interacts with
+> > interface types.
+
+What other kind of questions would you have? :-)
+
+...
+> > with A1.A2;
+> > with Some_Other_Pkg;
+> > package Foo is
+> > type Grandchild is new A1.A2.Child and Some_Other_Pkg.Ifc with
+> > private; procedure P1 (X : Grandchild); private type
+> Grandchild is new
+> > A1.A2.Child and Some_Other_Pkg.Ifc with null record;
+> procedure P2 (X :
+> > Grandchild); end Foo;
+
+Well, *clearly* the new rules cannot apply here as there is no keyword
+"overriding". In the interests of compatibility, we surely intend no change in
+the absense of that keyword. So I think the question is irrelevant on this
+example (although maybe I've missed something - perhaps that is not reflected in
+the wording somehow??). OTOH, had the example included the keyword "overriding",
+then it gets interesting.
+
+with A1.A2;
+with Some_Other_Pkg;
+package Foo is
+   type Grandchild is new A1.A2.Child and Some_Other_Pkg.Ifc with private;
+   procedure P1 (X : Grandchild);
+private
+   type Grandchild is new A1.A2.Child and Some_Other_Pkg.Ifc with null record;
+   overriding
+   procedure P2 (X : Grandchild);
+end Foo;
+
+I don't know the answer here, because I don't really understand the purpose of
+the phrase in question. "so long as a corresponding dispatching operation of
+some ancestor type is visible at the point of the explicit declaration." Are we
+trying to ensure that some version of this routine is visible at this point?
+
+Presuming that is the intent, then I do not agree that this wording is good
+enough. Both candidates are "corresponding" in some sense, and I'm not sure how
+we can tell that one is and the other is not. Maybe an AARM note would be
+convincing, but someone will have to write it.
+
+Note that one of the open AIs that we really ought to work on is that we don't
+even have a working definition of dispatching in the case of interfaces. (See
+AI05-0197-1). So this area is a complete mess.
+
+I truly hate interfaces... (not quite to the level of coextensions, but pretty
+close).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 10, 2011  10:42 PM
+
+> Perhaps a little clever formatting, or adding some wording to identify
+> which normative paragraphs each AARM note applies to.
+
+The problem here is that you put this wording in front of an existing 9
+paragraph AARM note. I don't think putting this at the end is going to help
+anything. :-)
+
+Actually, I see a problem here: you have this added wording, but it is going
+into a bulleted list immediately after an inner bulleted list. So does it belong
+to the inner list or the outer one? Is this one bullet or two? If it goes after
+the *inner* list (which seems to make more sense to me), then the preceding
+bullet needs work as well (this doesn't work after an "otherwise" bullet). If it
+*doesn't* go in the inner list, I don't see how it works in the interface case
+(where there is two homographs already); in that case, we'd select the previous
+bullet and never see this one.
+
+So please tell me what you had in mind here.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Tuesday, February 15, 2011  6:55 PM
+
+A few days ago, Steve posted the following example:
+
+> I have some corner-case questions about how this one interacts with
+> interface types.
+>
+> In the first paragraph of the proposed wording , it says
+>
+>      ... so long as a corresponding dispatching operation of some
+>      ancestor type is visible ....
+>
+> Consider the following variation on the example given in the AI:
+>
+>      package A1 is
+>         type Base is abstract tagged private;
+>         procedure P1 (X : Base);
+>      private
+>         type Base is tagged null record;
+>         procedure P2 (X : Base);
+>      end A1;
+>
+>      package A1.A2 is
+>         type Child is new Base with private;
+>         procedure P1 (X : Child);
+>      private
+>         type Child is new Base with null record;
+>         procedure P2 (X : Child);
+>      end A1.A2;
+>
+>      package Some_Other_Pkg is
+>         type Ifc is interface;
+>         procedure P2 (X : Ifc) is abstract;
+>      end Some_Other_Pkg;
+>
+>      with A1.A2;
+>      with Some_Other_Pkg;
+>      package Foo is
+>         type Grandchild is new A1.A2.Child and A1.A2.Ifc with private;
+
+A1.A2.Ifc => Some_Other_Pkg.Ifc
+
+>         procedure P1 (X : Grandchild);
+>      private
+>         type Grandchild is new A1.A2.Child and Some_Other_Pkg.Ifc
+>           with null record;
+>         procedure P2 (X : Grandchild);
+>      end Foo;
+>
+> We replaced A1.A3 with Foo, so we lose all visibility there into A1's
+> private part. One might think that this would mean that the the new
+> wording no longer applies, but we have this interface type IFc which
+> is a progenitor of Grandchild and has a P2 with the right profile. So
+> does the wording apply? Does this mean that the AI introduces unwanted
+> overriding? Or does the word "corresponding"
+> (in the cited RM wording) *obviously* eliminate the problem.
+>
+> Perhaps there is no problem here, but it seems that we might want an
+> AARM note to clarify this situation.
+
+Like Randy, I'm also concerned about the use of "corresponding" in the rule,
+since it doesn't clearly say what corresponds to what, though I think I know
+what's meant.  If we stick with this basic wording, that should be clarified if
+possible.
+
+However, I think there's another problem with the proposed rule that kicks out
+Steve's example before we even get to worrying about "corresponding".
+
+(For reference, the wording is:
+
+  When a type extension inherits a subprogram that is never declared
+  (see 7.3.1) and is not a homograph of an inherited subprogram that is
+  declared, an explicit declaration of a dispatching operation with the
+  same defining name and a type-conformant profile will nevertheless
+  override the inherited subprogram (for the purposes of dispatching
+  calls), so long as a corresponding dispatching operation of some
+  ancestor type is visible at the point of the explicit declaration.
+  Such an overriding requires an overriding_indicator, which shall be
+  OVERRIDING (see 8.3.1).
+)
+
+The way I read this, the example is legal because the never-declared subprogram
+is "a homograph of an inherited subprogram that is declared", namely the P2
+coming from the interface, so the rule doesn't apply. Fine, we don't want it to
+apply (though perhaps not for that reason:-).
+
+However... this does bring to mind a variation on the above where it seems that
+the rule won't apply when it should.  What if we change Foo back to being a
+child unit, so the ancestor subprogram *is* visible. The rule still won't apply
+(again because the never-declared subprogram is a homograph of the
+interface-inherited P2), but I certainly assume that it's intended to apply in
+that case.  That is, overriding of the never-declared subprogram should occur.
+After all, I don't think we want overriding of the ancestor operation to
+suddenly be suppressed as a result of adding a dependence on an interface.
+
+So it appears that at least the first part of the rule doesn't have quite the
+right effect.
+
+It seems that somehow the "and is not a homograph of an inherited subprogram"
+wording needs to be changed so that it only means subprograms that are inherited
+from ancestors in the chain of types that's the source of the never-declared
+subprograms, though that might be difficult to phrase properly.
+
+----
+
+One other small comment on the AARM paragraph in 8.3(10.d):
+
+  Modify 8.3(10.d):
+
+    As explained in 7.3.1, "Private Operations", some inherited primitive
+    subprograms are never declared. Such subprograms cannot{, in general,}
+    be overridden, although they can be reached by dispatching calls in
+    the case of a tagged type.
+
+I think we should add a reference to the new rules in 8.3.  Something
+like:
+
+    "(For a case where such overriding can occur, see 8.3(12.xx).)"
+
+----
+
+BTW, the sentence in the second added 8.3 paragraph in !wording must be a strong
+contender for the prize of longest RM sentence -- it goes on for ten lines!
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Tuesday, February 15, 2011  7:27 PM
+
+...
+> (For reference, the wording is:
+>
+>   When a type extension inherits a subprogram that is never declared
+>   (see 7.3.1) and is not a homograph of an inherited subprogram that is
+>   declared, an explicit declaration of a dispatching operation with the
+>   same defining name and a type-conformant profile will nevertheless
+>   override the inherited subprogram (for the purposes of dispatching
+>   calls), so long as a corresponding dispatching operation of some
+>   ancestor type is visible at the point of the explicit declaration.
+>   Such an overriding requires an overriding_indicator, which shall be
+>   OVERRIDING (see 8.3.1).
+> )
+>
+> The way I read this, the example is legal because the never-declared
+> subprogram is "a homograph of an inherited subprogram that is
+> declared", namely the P2 coming from the interface, so the rule
+> doesn't apply.
+> Fine, we don't want it to apply (though perhaps not for that
+> reason:-).
+>
+> However... this does bring to mind a variation on the above where it
+> seems that the rule won't apply when it should.
+> What if we change Foo back to being a child unit, so the ancestor
+> subprogram *is* visible.
+> The rule still won't apply (again because the never-declared
+> subprogram is a homograph of the interface-inherited P2), but I
+> certainly assume that it's intended to apply in that case.
+
+Well, I asked a version of this question last week. Part of the problem is that
+I have no idea into which bulleted list this wording is supposed to go (the
+specified position is at the end of one inner list in the middle of an outer
+list). And so far as I can tell, either choice is wrong.
+
+If it goes into the inner list, it only applies where there are "two or more
+homographs implicitly declared". That's clearly wrong - there might not be any
+implicit declarations.
+
+If it goes into the outer list, it only applies when there are *not* "two or
+more homographs implicitly declared" (because there is already a bullet starting
+that way, and we don't want bullets that overlap). But that means that if there
+are homographs, the rule cannot apply (even if it should because of
+progenitors).
+
+Without some resolution of which list this goes into, it isn't even possible to
+consider how to fix the wording. And in all honestly, I don't see any way to
+make it work for the interface case. (Indeed, I've forgotten why we would want
+it to work for that case...have to go back and look at the examples again.)
+
+Anyway, this wording doesn't work, and we'll have to come up with something else
+at the meeting.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent