Re: Dispatch on the result still does not work?

[Adam Beneschan <adam@irvine.com>]

On Jul 11, 3:04 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Considering this one:
>
> package P is
>    type T is tagged null record;
>    function Value return T;
>
>    type S is new T with null record;
>    function Value return S;
> end P;
>
> package body P is
>    function Value return T is
>    begin
>       return (null record);
>    end Value;
>
>    function Value return S is
>    begin
>       return (T with null record);
>    end Value;
> end P;
>
> use P;
>
>    X : T'Class := S'(Value);
> begin
>    X := Value; -- Ambiguous?
>
> I would expect it rather dispatching on the tag of X, i.e. selecting Value,
> which returns S.

The problem here (I mean the problem with your program, not a problem
with the Ada language) is that the overloading rules, which determine
what the meaning of the identifier "Value" is when there is more than
one possibility, do not take the dynamic semantics into account.  The
overloading rules basically work like this: We consider all possible
combinations of all possible meanings of the identifiers, then keep
only the legal ones (legal according to the "legality rules"; a
construct can still be legal even if it will always raise an exception
at runtime).  If there is more than one legal possibility, the
construct is ambiguous.  (This oversimplifies things a bit; there are
some exceptions regarding abstract subprograms.)

Or, to put it another way: The compiler *first* has to determine what
each of the identifiers in the statement means.  Only after this is
determined, *then* can it apply the dynamic-semantics rules about
dispatching.

Suppose the Value that returns T does not exist:

  package P is
     type T is tagged null record;
  -- function Value return T;

     type S is new T with null record;
     function Value return S;
  end P;
  ...

  use P;

     X : T'Class := S'(Value);
  begin
     X := Value;

The question here is, is the assignment statement legal?  And the
answer is "Yes", because the expected type (the type of X) is T'Class,
and the type of Value is S, which is a type in that class (8.6(21)).
Since this is legal, then if we uncomment the first Value, there would
be two legal interpretations for the statement "X := Value", which
makes it ambiguous.

I believe this will work, although I'm not 100% certain; it is legal
and will dispatch, although the syntax could possibly make it look
like it won't dispatch:

     X : T'Class := S'(Value);
  begin
     X := T'(Value);

Making the call to Value a "qualified expression" tells the compiler
what the expected type of Value will be, and thus helps it determine
unambiguously which Value is meant.  If I have this straight, using a
qualified expression doesn't change the fact that the expression
("Value") is tag-indeterminate; and thus the assignment is still legal
by 5.2(6), and the call still dispatches by 3.9.2(18.1).

I think this also works:

     X : T'Class := S'(Value);
  begin
     declare
        function T_Value return T renames Pak1.Value;
     begin
        X := T_Value;
     end;

Again, the rename helps the compiler determine unambiguously which
Value subprogram is intended, but it doesn't change the fact that the
call to it is tag-indeterminate.  I'd need to pore over the rules more
closely to make sure of this, however.

Anyway, the important thing to remember is that the compiler first has
to determine which declaration is meant by every identifier in a
statement, and only *then* can it think about whether a call is
dispatching or not.

Hope this helps,

                                       -- Adam