!standard  4.1(2)                                    06-03-15    AI05-0003-1/01
!standard  4.7(0)
!class Amendment 05-10-24
!status work item 06-03-15
!status received 05-09-20
!priority Medium
!difficulty Medium
!subject Qualified expressions and "names"

!summary

(See proposal.)

!problem

A function_call can be used as a "name". Thus, for example, it can be
used as the prefix of a component selector or array index.

If a function is overloaded, one of the ways to disambiguate a
function call is to use a qualified expression to tell the compiler
what the return type of the function is supposed to be.

However, although the function_call can be used as a "name", a
qualified expression can't---it's not in the syntax of "name".  So if
you want to use a function_call as a "name", but you need to use a
qualified expression to disambiguate it, you can't. This should be fixed
somehow.

!proposal

One option is to keep "name" as is, but make
"prefix" more flexible. We're not looking to
allow more things on the LHS of an assignment or as an OUT
parameter.  Mostly we want to be able to use <blah>.component
or <blah>(index) or <blah>.all, without getting slapped
on the wrist because <blah> is not "officially" a "name."

!wording

!discussion

!example

!ACATS test

!appendix

!topic Qualified expressions and "names"
!reference RM95 4.1(2), 4.7
!from Adam Beneschan 09-20-05
!discussion

This is a minor point, but it might be worth considering (probably not
for 0Y but maybe in the future).

A function_call can be used as a "name".  Thus, for example, it can be
used as the prefix of a component selector or array index.  I don't
know how often this is actually done in practice.  Also, now that
Object.Operation is one form of component selection (AI-252), it may
be that this will be done more often.

If a function is overloaded, one of the ways to disambiguate a
function call is to use a qualified expression to tell the compiler
what the return type of the function is supposed to be.

However, although the function_call can be used as a "name", a
qualified expression can't---it's not in the syntax of "name".  So if
you want to use a function_call as a "name", but you need to use a
qualified expression to disambiguate it, you can't.

May I suggest that the definition of "name" be expanded to include
qualified expressions of the form subtype_mark'(expression) where
"expression" is a function_call?

I'll admit that this isn't an important change---it's pretty obscure.
But it would plug what seems to be a little hole in the language.  It
shouldn't have much impact on the rest of the RM (he said hopefully),
since a qualified expression of that form would be semantically
exactly the same as the function call inside the qualified expression.
Plus it shouldn't be too difficult to implement.

****************************************************************

From: Tucker Taft
Date: Tuesday, September 20, 2005  1:41 PM

This whole distinction between what is a name and what is an expression
is annoying, and should probably be eliminated.  We should have
done it in Ada 95, and probably should have done it in Ada 2005.
It just never made it up high enough on the priority list...

I suppose one option is to keep "name" as is, but make
"prefix" more flexible.  I don't think we are looking to
allow more things on the LHS of an assignment or as an OUT
parameter.  Mostly we want to be able to use <blah>.component
or <blah>(index) or <blah>.all, without getting slapped
on the wrist because <blah> is not "officially" a "name."

****************************************************************

From: Adam Beneschan
Date: Tuesday, September 20, 2005  2:00 PM

> I suppose one option is to keep "name" as is, but make
> "prefix" more flexible.

I like that idea a lot better than the one I came up with.

****************************************************************

Editor's note, August 3, 2007

One possible fix for the problem of the not quite equivalent equivalence
rule in 6.6(2) would be to reduce or eliminate the difference between
expressions and names. The problem is that an infix operator call is
an expression, not a name, while the supposedly equivalent function call
is a name. Thus is it illegal to rename the result of an expression:
    Val : Integer renames A + 3; -- Illegal
even though the equivalent prefix call is legal:
    Val : Integer renames "+"(A, 3); -- Legal

See AC-00143 for a thread about this problem and its effects.

****************************************************************