-
Notifications
You must be signed in to change notification settings - Fork 93
Description
The final para of §6.2.5 is:
When recognising a relational_expression (§12.12.1) if both the “relational_expression
istype” and “relational_expressionispattern” alternatives are applicable, and type resolves to an accessible type, then the “relational_expressionistype” alternative shall be chosen.
The rest of §6.2.5 is about disambiguation type_argument_list, and this para is just about
lost after the disambiguation examples. This information should be relocated to §12.12.1 (relational_expression) and/or §12.12.12 (is operator).
In §12.12.1 following the grammar for relational_expression & equality_expression there
is:
Note: Lookup for the right operand of the
isoperator must first test as a type, then as an expression which may span multiple tokens. In the case where the operand is an expression, the pattern expression must have precedence at least as high as shift_expression. end note
“must have” sounds rather normative for a non-normative note, and the statement “precedence at least as
high as shift_expression” is rather curious without further explanation – if precedence prevents
the writing of what is required then using parenthesis is usually indicated, which is supported
by expression, and something the Standard doesn’t repeat all over the place…
In §12.12.12 and its two subclauses on the is-type & is-pattern operators there is no mention of
disambiguation between them or of any precedence requirements.
The current text in §6.2.5 probably needs to be incorporated into §12.12.1/12, and that in §12.12.1 at minimum revised.
Note that is will change in v9, including the is-type/is-pattern distinction,
which should be kept in mind in any fix-up now. Marking this as v8 for now…