Re: prefix of dereference must be a name?

["Yannick Duchêne Hibou57" <yannick_duchene@yahoo.fr>]

On 4 août, 03:45, Adam Beneschan <a...@irvine.com> wrote:
> 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

Although I agree about your arguments for a more intuitive and less
badly-restrictive syntax, I still try to understand why it is like it
is, and I suppose there were some good reasons, like avoiding too
much deep expressions. Perhaps it was in the hope it would help
readability and maintenance, forcing the decomposition of some
expressions in intermediate steps.

While for the simple example you gave, “ Type'(Function_Call(...)) ”,
this hypothetical reason would surely not apply.