Skip to content

Issues with is-operator ($12.12.12, §12.12.1, §6.2.5) #1285

@Nigel-Ecma

Description

@Nigel-Ecma

The final para of §6.2.5 is:

When recognising a relational_expression (§12.12.1) if both the “relational_expression is type” and “relational_expression is pattern” alternatives are applicable, and type resolves to an accessible type, then the “relational_expression is type” 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 is operator 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…

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions