1

[{*precedence of operators*}
{*operator precedence*} The
language defines the following six categories of operators (given in order of
increasing precedence). The corresponding operator_symbols,
and only those, can be used as designators
in declarations of functions for user-defined operators. See 6.6,
``Overloading of Operators''.]

2

3

4

5

6

7

7.a

8

For a sequence of operators of the same precedence
level, the operators are associated with their operands in textual order
from left to right. Parentheses can be used to impose specific associations.

8.a

8.b

See the Implementation Permissions
below regarding flexibility in reassociating operators of the same precedence.

9

{*predefined operator*}
{*operator (predefined)*} For
each form of type definition, certain of the above operators are *predefined*;
that is, they are implicitly declared immediately after the type definition.
{*binary operator*} {*operator
(binary)*} {*unary operator*}
{*operator (unary)*} For
each such implicit operator declaration, the parameters are called Left and
Right for *binary* operators; the single parameter is called Right for
*unary* operators. [An expression of the form X op Y, where op is a binary
operator, is equivalent to a function_call
of the form "op"(X, Y). An expression of the form op Y, where op is
a unary operator, is equivalent to a function_call
of the form "op"(Y). The predefined operators and their effects are
described in subclauses 4.5.1 through 4.5.6.]

10

[{*Constraint_Error
(raised by failure of run-time check)*} The predefined
operations on integer types either yield the mathematically correct result or
raise the exception Constraint_Error. For implementations that support the Numerics
Annex, the predefined operations on real types yield results whose accuracy
is defined in Annex G, or raise the exception Constraint_Error.
]

10.a

11

{*Constraint_Error (raised by
failure of run-time check)*} The implementation
of a predefined operator that delivers a result of an integer or fixed
point type may raise Constraint_Error only if the result is outside the
base range of the result type.

12

{*Constraint_Error (raised by
failure of run-time check)*} The implementation
of a predefined operator that delivers a result of a floating point type
may raise Constraint_Error only if the result is outside the safe range
of the result type.

12.a

13

For a sequence of predefined operators of the
same precedence level (and in the absence of parentheses imposing a specific
association), an implementation may impose any association of the operators
with operands so long as the result produced is an allowed result for
the left-to-right association, but ignoring the potential for failure
of language-defined checks in either the left-to-right or chosen order
of association.

13.a

13.b

Note that this permission does
not apply to user-defined operators.

NOTES

14

11 The two operands of an expression
of the form X op Y, where op is a binary operator, are evaluated in an arbitrary
order, as for any function_call (see 6.4).

15

16

X > 4.0

17

Y**(-3)

A / B * C

A + (B + C)

17.a

We don't give a detailed definition
of precedence, since it is all implicit in the syntax rules anyway.

17.b

The permission to reassociate
is moved here from RM83-11.6(5), so it is closer to the rules defining
operator association.