Dealing with var, parts 1 and 2

[BillWagner]

Fixes #1663
Fixes #1665

Because these are related, and small in scope (even if combined) put them both in one PR:

1. A var_pattern can't be used if an identifier var is in scope.
2. If var is a type in scope, it can't be used as a declaration_pattern. However, other "spellings" of var are allowed as a type.

[jskeet]

Just to set expectations, I'm out for the next week or so - will review all of these pending PRs when I get back.

[Nigel-Ecma]

Unfortunately poking these issues brings out more :-(

---

If I am reading this correctly the Note on line 89 contains normative information. I think the cases maybe:

When there is no declaration of var:

• Then var x; where x is an discard, identifier, tuple; is a var_pattern

When a type declaration for var is in scope:

• Then var x is neither a var_pattern or declaration_pattern
• However @var x; and other ugly ways to write “var”; is a declaration_pattern

When var is declared in scope as something other than a type:

• I’ve no idea offhand

I don’t think this is clear in the text of either §11.2.2 or §11.2.4

Would it be better if these two clauses were adjacent? Indeed maybe investigating a “Declaration patterns” clause with subclauses General (includes the disambig stuff), Explicitly typed (declaration_pattern), and Implicitly type (var_pattern), could be considered?

---

Tuples: consider the ways to match a pair of ints:

• (int, int) x – declaration_pattern
• `var (x, y) – var_pattern
• (int x, int y) - positional_pattern
• (int, int) (x, y) – syntactically invalid

Should this be made clear somewhere?

---

dynamic: The syntax of declaration_pattern permits dynamic but this is I understand invalid as the semantics are defined in terms of is (line 91) which disallows dynamic. This should be covered in §11.2.2

[BillWagner]

2nd commit addresses #1696 (review).

I knew this looked to easy.

First, moved "Constant Pattern" before "Declaration Pattern". Now, declaration_pattern and var_pattern are adjacent. That should make it easier to determine if we want to combine them. The flow seems reasonable.

Next, handle var in general. I moved these rules into the "general" section, because they apply across all patterns. If var is an identifier, it binds to that element. If var is a constant, it's a constant pattern. If it's a type, it's a type pattern. If it's a variable, it's an invalid pattern. (Similarly if its a method group or namespace).

Finally, add a note about how tuple literals are parsed as different patterns depending on their form.

[BillWagner]

@Nigel-Ecma I believe I've addressed your review comments. Can you take another look?

[jskeet]

Will look again once the constant pattern movement has been sorted out, to avoid missing something.

[jskeet]

Not sure about the verbatim identifier part - that would suggest this should compile:

using System;

class @var {}

class Test
{
    static void Main()
    {
        object x = "";
        if (x is var y)
        {
            Console.WriteLine("yes");
        }
    }
}

... but it doesn't. I think you're trying to say that using @var in a pattern isn't equivalent to using var, but if that's the case, we should be more explicit about it.

[jskeet]

I'm not sure what "in pattern position" means here. (I suspect just adding a couple of words will be fine.)

[jskeet]

Whatever we decide to do, we should apply to line 191 as well.

[Nigel-Ecma]

@jskeet – I think the intention is “is not valid as the first token of a pattern”

[Nigel-Ecma]

A step in the right direction, but describing this cleanly is a challenge… :-(

[Nigel-Ecma]

I believe this is incorrect, once var is declared as a type then it cannot be used as the type in a declaration_pattern – you must go ugly (@var et al) – but it can be used in is *type*[*].

If var is declared as a constant then both is var – constant_pattern and is var y – var_pattern are valid. However is @var y is invalid as that references the constant…

Or something like that!

[*] This is testing for v8, for v9 is *type* vs is *pattern* where pattern is type_pattern throws a spanner, and the rest of the toolbox, into the works as both in theory exist and have different semantics yet are syntactically indistinguishable – at least that’s what the source material says…

[Nigel-Ecma]

@jskeet – I think the intention is “is not valid as the first token of a pattern”

[jskeet]

@jskeet is taking an action to create as exhaustive a list of test cases as feasible.

[jskeet]

Starting point of test cases:

#if VAR_IS_NAMESPACE
namespace var
{
#endif

    public class VarTests
    {
#if VAR_IS_CONSTANT
    private const int var = 5;
#elif VAR_IS_TYPE
    private class @var { }
#endif

        static void Tests()
        {
            object o = new object();

            bool t1 = o is var;
            bool t2 = o is @var;
            bool t3 = o is (var);
            bool t4 = o is (@var);
            if (o is var t5) { }
            if (o is @var t6) { }
            if (o is (var t7a, var t7b)) { }
            if (o is (@var t8a, @var t8b)) { }
        }
    }
#if VAR_IS_NAMESPACE
}
#endif

The t3 and t4 cases exist for the sake of C# 9, where the rules will change slightly.

Note: when var refers to a namespace,

Without defining anything:

• t1 fails with "The contextual keyword 'var' may only appear within a local variable declaration or in script code"
• t2, t6, t8 fail with "The type or namespace name 'var' could not be found (are you missing a using directive or an assembly reference?)"
• t3, t4 fail with "The name 'var' does not exist in the current context"
• t5, t7 are valid

With VAR_IS_NAMESPACE defined:

• t1, t2, t6, t8 all fail with "'var' (or '@var') is a namespace but is used like a type"
• t3, t4 fail with "'var' is a namespace but is used like a variable"
• t5 and t7 are valid

With VAR_IS_CONSTANT defined:

• t6 and t8 fail with "The type or namespace name 'var' could not be found (are you missing a using directive or an assembly reference?)"
• t1, t2, t3, t4, t5, t7 are valid

With VAR_IS_TYPE defined:

• t5 and t7 fail with "The syntax 'var' for a pattern is not permitted to refer to a type, but 'VarTests.var' is in scope here."
• t3, t4 fail with "Feature 'type pattern' is not available in C# 8.0. Please use language version 9.0 or greater."
• t1, t2, t6 and t8 are valid

[BillWagner]

@jskeet I removed the meeting discuss label on this one. Go ahead and add it back if you want to discuss the tests you've added.

[BillWagner]

I've addressed all unresolved comments and validated the language against the tests Jon added.

[jskeet]

LGTM, thanks for the clarifications.

[jskeet]

Punted in the meeting due to @Nigel-Ecma's absence - we'll see if we can discuss and address offline between meetings.

[BillWagner]

The base branch draft-v8 has been updated following the latest TC49-TG2 committee meeting. Please rebase this PR onto the latest draft-v8 and resolve any conflicts. Thanks!

[Nigel-Ecma]

I think the description of var handling “in a pattern” is unintentionally misleading as the handling follows that of other contextual keywords, the description lacks any reference to §6.4.

I also think a simpler/clearer approach is to follow the usual one of dealing with contextual keyword vs. identifier resolution in context at the source.

So I’ve made suggestions which delete some of the changes and rephrase others. There are a few other related odds'n'ends as well.

[Nigel-Ecma]

The introduction of contextual keywords and discards to C# while also maintaining the ability to use the same identifiers in user-defined ways allows for potential confusion but is generally not remarked upon unless rules, such as disambiguation, are required. So why remark on it here?

In this particular situation if var is defined as a constant then the input var can itself be a pattern which might to some be potentially confusing with the var x pattern… Is this more confusing than the general cases caused by contextual keywords and so worthy of note?

If it is thought not then this addition becomes redundant:

Suggested change

	When a declaration of the *identifier* `var` in scope resolves to a constant, `var` may appear as the *constant_expression* of a *constant_pattern*; the general rule for the *identifier* `var` in patterns is specified in [§11.2.1](patterns.md#1121-general).

If it is deemed worthy of explanation then this addition should become a Note explaining the potential confusion:

Suggested change

	When a declaration of the *identifier* `var` in scope resolves to a constant, `var` may appear as the *constant_expression* of a *constant_pattern*; the general rule for the *identifier* `var` in patterns is specified in [§11.2.1](patterns.md#1121-general).
	> *Note*: Come up with a short clear wording stating that using `var` as a constant in a context where patterns are used could be confusing – this is left as an exercise… *end note*

Take your pick (or neither of course!)

[Nigel-Ecma]

As far as I can see there is no such thing as a “deconstruction declaration”, also found on line 261. Are these two uses accidental (untranslated?) copies from some source material or am I missing something?

[Nigel-Ecma]

This reads, along with references in the changes below back to here stating (emphasis added):

the general rule for the identifier var in patterns is specified in §11.2.1

as though the recognition of var in this context is somehow special.

However var is recognised according to the token rules of §6.4 and the pattern grammar rules; just as uses of contextual keywords elsewhere are. What may differ in any location where a contextual keyword is used are the disambiguation rules that apply if there is a definition in scope with the same name (§6.4.4).

Those disambiguation rules are usually stated close to the source of the ambiguity, which in this case would be in the subclauses for constant, declaration and var patterns; in this case they have been split between here and the relevant subclauses. I don’t see that this gains anything.

Rewording to address these issues could be considered, e.g. by including references back to §6.4 and making it clear the process follows the usual model.

However instead I suggest simply deleting the text here and handling var on a case-by-case basis in the following clauses.

Suggested change

	The token `var` in a *pattern* is recognised as the contextual keyword of a *var_pattern* ([§11.2.4](patterns.md#1124-var-pattern)) only in the form `var` *designation*. The verbatim identifier `@var` and Unicode-escaped spellings of `var` are never recognised as the contextual keyword of a *var_pattern*; they are ordinary identifiers denoting whatever entity is in scope. A pattern that uses such a spelling is therefore interpreted as a *declaration_pattern*, *constant_pattern*, or other pattern form according to the entity that the identifier denotes.
	When a declaration of the *identifier* `var` is in scope, the following rules apply:
	- If `var` denotes a type, then the plain token `var` cannot be used as the *type* of a *declaration_pattern*; that type shall be named another way, such as by the verbatim identifier `@var`.
	- If `var` denotes a constant, then `var` may be the *constant_expression* of a *constant_pattern* ([§11.2.3](patterns.md#1123-constant-pattern)).
	- Otherwise (for example, when `var` denotes a namespace, field, property, local variable, parameter, or any other entity that is neither a type nor a constant), `var` is not valid as the first token of a *pattern* unless it is used in the form `var` *designation*.

[Nigel-Ecma]

I don't think stating that the definition of C# is determined by “empirical testing” is how formal language semantics are decided – even if replacing formal definition with empirical observation might be becoming de rigueur for AI software specification 😉

So I will again delete this text as the simplest option, if is not then at minimum it needs rephrasing.

Suggested change

<!-- C# 9 update marker: the committee's empirical testing shows that in C# 8, when `var` names a type, `o is (var)` and `o is (@var)` fail CS8400 because type patterns are not available; in C# 9 they bind as *type_pattern*s and are valid. Draft-v9 should update this boundary for type patterns and parenthesized patterns, while preserving that bare `is T` and pattern `is (T)` are distinct grammar/binding paths. -->

[Nigel-Ecma]

This is a curious case, why does the declaration pattern differ in its handling of var compared to the declaration statement? I.e. if var is, say, a user-defined class type; then var x declares x to be of type var when the tokens appear in the context of a declaration statement, and the token sequence is invalid if they appear in the context of a declaration pattern – why the difference?

Assuming this difference is intentional we fortunately we are not required to provide the rationale, we just need to state the rule:

Suggested change

	When a declaration of the *identifier* `var` in scope resolves to a type, the plain token `var` cannot appear as the *type* of a *declaration_pattern*; that type shall be named another way, such as by the verbatim identifier `@var`. The general rule for the *identifier* `var` in patterns is specified in [§11.2.1](patterns.md#1121-general).
	A *declaration_pattern* cannot be used to test that a value has a type named `var` unless that type is referenced using an identifier containing a unicode character escape sequence ([§6.4.2](lexical-structure.md#642-unicode-character-escape-sequences)) or represented by an *Escaped_Identifier* ([§6.4.3](lexical-structure.md#643-identifiers)).

An example could be included which, say, declares a class var and then uses @var and/or v\u0061r in declaration patterns. Here is one which is not included in the above suggestion as it feels far too long, I expect others will do better:

Example: Given the definition of a class var and a variable x of that type:

class var { ... }

Then testing whether a variable x is of type var using the is-type operator (§12.14.12.1):

if (x is var) ...

is valid. However a similar test using the is-pattern operator (§12.14.12.2):

if (x is var y) ...

is a compile-time error. However the following:

if (x is v\u0061r y) ...
if (x is @var z) ...

are both valid uses of the is-pattern operator with a declaration_pattern.

end example

[Nigel-Ecma]

The “because…” is surely wrong as nothing has the runtime type of dynamic? I suggest just:

Suggested change

	The *type* of a *declaration_pattern* cannot be `dynamic`, because the runtime type test is defined in terms of the is-type operator ([§12.14.12.1](expressions.md#1214121-the-is-type-operator)), which does not permit `dynamic`.
	The *type* of a *declaration_pattern* cannot be `dynamic`.

and avoid getting into why.

[Nigel-Ecma]

Following the previous suggested changes we need to delete the x-ref as it now goes nowhere, and a slight rewording suggestion:

Suggested change

	A *var_pattern* cannot be used when the plain token `var` would refer to an in-scope type named `var`. See [§11.2.1](patterns.md#1121-general) for the interpretation of `var` when it is the first token of a *pattern* in that case.
	A *var_pattern* cannot be used when there is an in-scope type named `var`.

Is it worth adding a Note that there is/is not no easy workaround in such as case?

[Nigel-Ecma]

This is just a repeat of line 33, repeating it is harmless but it should be a true repeat:

Suggested change

	It is an error if a *positional_pattern* omits the type, has a single *subpattern* without an *identifier*, has no *property_subpattern* and has no *simple_designation*. This disambiguates between a *constant_pattern* that is parenthesized and a *positional_pattern*.
	If the input can be syntactically recognised as both a *constant_pattern* and a *positional_pattern* then the *constant_pattern* shall be chosen.

Note that neither location contains an ANTLR comment as some other similar cases do, in this case it would be:

Note: ANTLR makes the specified choice automatically due to the ordering of the alternatives of pattern. end note

Adding it to line 33 could be done, I wouldn't add it at both locations.