AI22-0064-1
!standard 4.4(8) 23-04-05 AI22-0064-1/03
!standard 4.4(9.1/5)
!standard 4.4(10.1/5)
!class binding interpretation 23-03-22
!status Amendment 1-2022 23-06-26
!status WG9 Approved 23-10-12
!status ARG Approved 6-0-0 23-06-11
!status work item 23-02-22
!status received 23-02-22
!submitter Randall Brukardt
!priority Low
!difficulty Easy
!qualifier Omission
!subject Basic rules for parenthesized expressions
Parenthesized expressions have the obvious resolution and evaluation rules.
In AI12-0066-1, we decided not to fix certain obvious missing rules in Ada. In particular, we didn't define the properties of a parenthesized expression. But we've continued to nibble at that in later AIs, adding a definition for the term parenthesized expression and the term operative constituent. We should complete the job rather than leaving these rules to the imagination.
(See Summary.)
Add after 4.4(8): [in Name Resolution Rules]
A primary that is an expression surrounded by ( and ) is known as a parenthesized expression; the expression of a parenthesized expression is the operand of the parenthesized expression. If a parenthesized expression is expected to be of type T, the expected type of the operand is T. Similarly, if the parenthesized expression is expected to be of some class of types, the operand of the parenthesized expression is expected to be of the same class of types.[a]
[Editor's notes: we define the meaning of "operand" for type conversions and qualified expressions, we ought to do so for parenthesized expressions as well, especially as 4.4(9.4/5) uses "operand" with parenthesized expressions.
The formulation of the exact resolution rules is based on that for conditional expressions. We do not need to mention the shall resolve to case anymore as qualified expressions now define an expected type.]
Delete 4.4(9.1/5). [moved above]
Add after 4.4(10.1/5): [in Dynamic Semantics]
The evaluation of a parenthesized expression evaluates the operand of the parenthesized expression, and yields the result of the operand evaluation.
AARM Ramification: There is no other (dynamic) effect[b][c]; there is no check or conversion associated with this evaluation. Of course, the parenthesized expression could be subject to a check or conversion depending on the context in which it is used.
[Editor's note: I find it odd that 4.4 doesn't say anything about evaluation of an expression, but most of the individual constructs have such rules given in their respective sections. Of course, there are no such rules elsewhere for parenthesized expressions, so I add one here. The wording is based on that for qualified expressions. I don't talk about the result as it is unchanged and the more said, the more likely an error is introduced.]
The addition of the term parenthesized expression and the term operative constituent were fixes in Ada 2022 to ensure that properties are correctly defined for various related constructs including parenthesized expressions. For instance, we have taken great care to ensure that whether an entity is newly constructed flows through parenthesized expressions. It seems weird to then ignore just the name resolution and evaluation of the construct.
[Editor's note: The other items of AI12-0066-1 are covered in AI22-0067-1, AI22-0072-1, and AI22-0066-1 (which is the counterpart of AI12-0066-1 for Ada 2022).]
@dinsa
A @fa{name} used as a @fa{primary} shall resolve to denote an object or a value.
@dinst
A @fa{primary} that is an @fa{expression} surrounded by ( and ) is known as a @i{parenthesized expression}; the @fa{expression} of a parenthesized expression is the @i{operand} of the parenthesized expression. If a parenthesized expression is expected to be of type @i{T}, the expected type of the operand is @i{T}. Similarly, if the parenthesized expression is expected to be of some class of types, the operand of the parenthesized expression is expected to be of the same class of types.
@ddel
A @fa{primary} that is an @fa{expression} surrounded by ( and ) is known as a @i{parenthesized expression}.
@dinsa
An expression of a numeric universal type is evaluated as if it has type @i{root_integer} (for @i{universal_integer}) or @i{root_real} (otherwise) unless the context identifies a specific type (in which case that type is used).
@dinst
The evaluation of a parenthesized expression evaluates the operand of the parenthesized expression, and yields the result of the operand evaluation.
These rules have been assumed by the ACATS going back to the original ACVC; further testing should not be needed.
[a]Steve Baird seems to think this second sentence is necessary. I can't decide for myself; conditional expressions are more complex than as there are multiple dependent expressions. I would have expected this sort of wording to be needed elsewhere in the standard, but only conditional expression and declare expression (which is a copy of the conditional expression case) has it. But there isn't anything else similar, either.
[b]Are there any things that are *lost* by parenthesizing something? It is no longer a "name" so it is no longer usable in a context where a name is required.
Does it lose its aliased-ness? That is not completely clear from RM 3.10. We might want to say something either here or in 3.10 about the view of the object provided by a parenthesized expression, if any, denoted by the operand. This seems necessary to properly deal with actuals passed to aliased IN formals.
There might be a more general problem identifying what is the "associated object" when passing a non-by-reference type to an aliased IN formal, and whether or not it is aliased -- perhaps another "obvious" AI? RM 6.2(10/5) defines generally what is the associated object of a by-reference type, but doesn't say anything about other types passed to aliased formals or used as a prefix of 'Access.
[c]This comment about "effect" was intended to be solely about dynamic effects, and I added "dynamic" to make that clear. The rest of it doesn't seem relevant to this AI which isn't intending to change any semantics.