Re: prefix of dereference must be a name?

[Adam Beneschan <adam@irvine.com>]

On Jul 30, 12:09 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> I'd like to be able to do the following:
>
> type T is record ... end record;
> type T_Access is access all T;
>
> function "+" (Left, Right in : ...) return T_Access;
>
> A : T_Access := new T;
> B : T_Access := new T;
> C : T_Access := A + B;
>
> A.all := (C + B).all;
>
> but GNAT complains that "prefix for selection is not a name", pointing
> to (C + B).all.
>
> So then I tried:
>
> function "-" (Token : in T_Access) return T_Access
> is begin
>     return Token;
> end;
>
> A.all := -(C + B).all;
>
> and got the same error. Finally I tried:
>
> function Copy (Token : in T_Access) return T_Access
> is begin
>     return Token;
> end;
>
> A.all := Copy (C + B).all;
>
> And the compiler was happy.
>
> What's the rationale for this?
>
> I assume one issue here is that "-" might be an intrinsic, but since
> the type involved is not a numeric type, I don't see how that could be
> a problem.
>
> Similarly for ().all; when could that be a problem?

You should look over AI05-0003.  I think there's a fair amount of
sympathy for your position; I agree that it would have been better to
have less distinction between "names" and "expressions", but the
problem just never made it high enough on the priority list.  It's
simple to say "You should be able to use an expression with an
operator wherever you could use the equivalent function call", but not
at all simple to change the language rules consistently and make sure
the change doesn't cause any other problems, and probably not at all
simple for all the compiler vendors to make the necessary changes.

AI05-0003 will fix one related issue, I think, to allow qualified
expressions [Type'(Function_Call(...))] to be used where they
currently can't.  I felt this one was important, because using
qualified expressions is sometimes the only reasonable way to
eliminate ambiguities in overloading cases---or at least the only non-
clunky way.  In your examples, you *could* always replace (A+B) with
"+"(A,B) to get around the problem, so it's not as important to have
this fixed, and a decision has to be made about whether it's worth the
effort.  But I agree that it would have been nice if the language had
been designed "right" at the beginning.

                                         -- Adam