Re: Equivalent of dynamic_cast (downcast) for tagged types

[Adam Beneschan <adam@irvine.com>]

On Jan 28, 1:16 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 27 Jan 2011 14:35:28 -0800 (PST), Maciej Sobczak wrote:
> > I have submitted this bug report more than one year ago. Looks like
> > nobody even bothered to check it.
>
> Well, I am not a language lawyer to tell if the behavior (public overriding
> of a private primitive operation) is legal.
>
> > The bug submission states that Adjust is wrongly recognized as
> > overriding, which it shouldn't be - but now I have hit something more
> > interesting.
>
> It must be overriding because Adjust is a primitive operation.

Wrong.

I can't find the language rule right now, but I'm certain that if a
tagged type T has a primitive operation Op declared in the private
part, and another package declares a type extension of T and declares
its own operation Op with the same profile, in a place where the first
Op is not visible, then the new Op is a **new** operation that has no
connection with the Op in the private part of the first package.  This
is what I would expect, since the private part of a package isn't
supposed to have any semantic effect on places that can't see the
private part.

Here's an example:

package Pak1 is
    type T1 is tagged null record;
    procedure Op1 (X : in out T1);
    procedure Test (Param : in out T1'Class);
private
    procedure Op2 (X : in out T1);
end Pak1;

with Ada.Text_IO;  use Text_IO;
package body Pak1 is
    procedure Op1 (X : in out T1) is
    begin
        Put_Line ("in Pak1.Op1");
    end Op1;

    procedure Op2 (X : in out T1) is
    begin
        Put_Line ("in Pak1.Op2");
    end Op2;

    procedure Test (Param : in out T1'Class) is
    begin
        Op1 (Param);
        Op2 (Param);
    end Test;

end Pak1;

with Pak1;  use Pak1;
package Pak2 is
    type T2 is new T1 with null record;
  --overriding                  ILLEGAL!
    procedure Op2 (X : in out T2);
end Pak2;

with Ada.Text_IO;  use Ada.Text_IO;
package body Pak2 is

    procedure Op2 (X : in out T2) is
    begin
        Put_Line ("in Pak2.Op2");
    end Op2;

end Pak2;


with Pak1;
with Pak2;
procedure Test87 is
    Y : Pak2.T2;
begin
    Pak1.Test (Y);
end Test87;

The Op2 defined in Pak2 has no connection with the Op2 defined in the
private part of Pak1.  It is not overriding.  And if Pak1.Op2 is
called as a dispatching operation, it will **not** dispatch to
Pak2.Op2, which is basically a new operation.  I compiled this with
GNAT and got

Pak1.Op1
Pak1.Op2

as expected.  (If you comment out the "private" keyword in Pak1, the
second line becomes Pak2.Op2.)

Furthermore, if the "overriding" line is uncommented, GNAT correctly
rejects the declaration, saying the procedure does not override
anything.

So since it's correctly rejecting the "overriding" in this case, but
not rejecting "overriding" on an Adjust operation of a type derived
from Limited_Controlled, there's definitely something amiss in the
compiler.  My guess is that the compiler handles (Limited_)Controlled
specially and thus doesn't quite go through the same path that it goes
through in my example.  But it's definitely a compiler bug, not a
portability issue.

                                  -- Adam