Version 1.1 of acs/ac-00143.txt

Unformatted version of acs/ac-00143.txt version 1.1
Other versions for file acs/ac-00143.txt

!standard 7.5(2.1/2)          07-08-03 AC95-00143/01
!class confirmation 07-08-03
!status received no action 07-08-03
!status received 07-06-25
!subject Limited type extensions and build-in-place
!summary
!appendix

!topic Does function_call include operators?
!reference 7.5(2.1)
!from Adam Beneschan 07-06-26
!discussion

7.5(2.1) says, "In the following contexts, an expression of a limited
type is not permitted unless it is an aggregate, a function_call, or a
parenthesized expression or qualified_expression whose operand is
permitted by this rule:" ...

Is it intended that an expression such as A+B, where "+" is a
user-defined function that returns a limited type, be prohibited in
this context?

The above language would make it seem that this is indeed prohibited,
since it refers to a "function_call" in the syntactic category font,
and the syntax of function_call (6.4(3)) only allows the name (or
prefix) of a function followed optionally by a parenthesized parameter
list.

But I'm guessing this isn't the intent.

In fact, it seems to contradict 6.5(5.5): "If the result subtype of
the function is limited, then the expression of the return statement
(if any) shall be an aggregate, a function call (or equivalent use of
an operator), or a qualified_expression or parenthesized expression
whose operand is one of these."  ("function call" is in a normal font
here and doesn't refer to a syntactic category.)  7.5(2.8) indicates
that a "return" statement is one of the contexts to which 7.5(2.1)
applies, so it appears that in answer to the question, "Is

   return A+B;

allowed in a function whose result type is limited?", 6.5(5.5) says
the answer is yes and 7.5(2.1-2.8) says the answer is no.

The use of the "function_call" syntactic category is probably
incorrect for the same reason in 7.5(8.1) and in several AARM
paragraphs following that.  I haven't looked at any sections outside
7.5 to see if function_call might be used incorrectly elsewhere.

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

From: Robert A. Duff
Sent: Saturday, June 30, 2007  9:17 AM

> Is it intended that an expression such as A+B, where "+" is a
> user-defined function that returns a limited type, be prohibited in
> this context?
...
> But I'm guessing this isn't the intent.

Me, too.

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

From: Randy Brukardt
Sent: Tuesday, July 31, 2007  5:31 PM

> 7.5(2.1) says, "In the following contexts, an expression of a limited
> type is not permitted unless it is an aggregate, a function_call, or a
> parenthesized expression or qualified_expression whose operand is
> permitted by this rule:" ...
>
> Is it intended that an expression such as A+B, where "+" is a
> user-defined function that returns a limited type, be prohibited in
> this context?
>
> The above language would make it seem that this is indeed prohibited,
> since it refers to a "function_call" in the syntactic category font,
> and the syntax of function_call (6.4(3)) only allows the name (or
> prefix) of a function followed optionally by a parenthesized parameter
> list.

The standard seems to take 6.6(2) literally, and expects operator calls to
be included in "function_call". There are rules going back to Ada 95 that
use "function_call" to include operators. For instance, 3.3(21); 3.9.2(15);
and 4.9(6). If we took Adam's intepretation,
operator calls return variables rather than constants, dispatching operator
calls on "=" raise Constraint_Error if the tags don't match, and operator
calls are never static. That's beyond silly.

The Amendment adds 3.3(10/2) [which is replaced by AI05-0015 anyway], the
three paragraphs that Adam mentioned, and 7.6.1(3/2) (defining masters).

There also are a lot of rules that say things like enumeration literals are
equivalent to parameterless function_calls. It would be necessary to check
these very carefully for similar problems. (There are 16 clauses that
include "function_call", excluding the index and syntax summary.)

As such, it seems like way too big a change for way too small of a problem.
(Which is annoying, because I just spent an hour writing up this change for
section 7, and now I'll have to spend some time backing it out.) Note that
there are 67 occurrences of "function_call" in the AARM, and 77 of "function
call". All would need to be checked to make a change.

---

Aside: I think Adam is technically correct, because a function_call is a
name, while an operator call is not a name. Thus an operator call cannot be
exactly equivalent to a function_call; treating it so would lead to
contradictions (for instance, you can't rename an object that is not a
name).

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

From: Adam Beneschan
Sent: Tuesday, July 31, 2007  5:56 PM

This does seem like an error in the RM.  But if it's too onerous to
fix, would it be helpful to add a "To be honest" note to the AARM,
either after 6.4(3) or 6.4(7.a), that wherever "function_call" is used
in the RM, except in 4.1(2), an equivalent use of an operator symbol
is also encompassed?  (The 4.1(2) exception would, I think, still make
it illegal for an object rename to rename an operator call, since the
object rename syntax refers to "_name_" and not to "function_call".)

My feeling is that if there had been an AARM note like that right near
the definition of "function_call", and I had spotted it, chances are I
wouldn't have even bothered to ask my question; it would have been
satisfactorily clear to me that an operator symbol would be allowed in
7.5(2.1).

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

Editor's note: This issue was decided to be not worth changing now
because it has been present in the standard since at least Ada 95
and no one was confused up to this point. We're currently correcting
the RM, not rewriting it, so an attempt to fix this could introduce
more errors and change than necessary.

We do believe that this is an issue that should be addressed the
next time there is a full revision of the Ada Standard. (Equivalence
rules never work, and this is just another example.)

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


Questions? Ask the ACAA Technical Agent