Re: Abstract Completion Question

[Robert A Duff <bobduff@world.std.com>]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> -- Consider the following code:
> 
> with Ada.Text_IO; use Ada.Text_IO;
> 
> procedure Test_1 is
> 
>    package P1 is
>       type T1 is abstract tagged null record;
>       procedure A (X: in T1) is abstract;
>    end;
> 
>    type T2 is new P1.T1 with
>       record
>          Data: String(1..10) := "***DATA***";
>       end record;
> 
>    procedure A (X: in T2) is
>    begin
>       Put_Line(X.Data);
>    end;
> 
>    type T1CA is access all P1.T1'Class;
> 
>    Y: aliased T2;
>    Z: T1CA := Y'Access;
> 
> begin
> 
>    P1.A(Z.all); -- dispatching call
> 
> end;
> 
> -- The operation "A" of type "T2" is overridden, so fulfilling the promise
> -- of type "T1" (as far as Ada is concerned).  This program compiles
> -- and runs (GNAT 3.11p Win32), but nevertheless "A" is not a primitive
> -- operation of "T2" (because it is not declared in a package spec), so
> -- "A" cannot be dispatched to.  Upon executing this program under
> -- GNAT, Constraint_Error is raised.  This behaviour could be a
> -- 'surprise' for users (a nasty one).  Comments?

Procedure A of T2 *is* primitive, because it overrides.  See 3.2.3(7).
The call should dispatch to this procedure A, as you would expect.

It's not clear to me why it's raising C_E -- perhaps a compiler bug, or
perhaps something I'm missing in the above code.

A language design goal was, "no dangling dispatching".  If you can
dispatch (legally at compile time), then there must be a procedure there
(at run time) to dispatch to.  If you find a violation of that
principle, I want to hear about it!

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.