I'm not sure this is by design or not, but simple name bind in constant pattern under is expression differs from ordinary member access bind or bind of constant pattern under case label:
```c#
using System;
class Foo {
public ClassVsProp ClassVsProp { get; }
public void M(object o) {
if ((string) o == ClassVsProp.Constant) { } // OK
// error CS0176: Member 'ClassVsProp.Constant' cannot be accessed
// with an instance reference; qualify it with a type name instead
if (o is ClassVsProp.Constant) { }
switch (o) {
case ClassVsProp.Constant: // OK
break;
}
}
}
class ClassVsProp {
public const string Constant = "abc";
}
```
I think the difference arises because syntax tree shape: simple syntax name node in o is ClassVsProp.Constant is not wrapped into constant pattern syntax node, since it's impossible to disambiguate it with ordinary type usage of is expressions.
cc @gafter
Simple and fully qualified identifiers in is and case do have different bindings, is defaults to types, and case defaults to constants. That is pre-C# 7 behavior, hence to retain backward compat they have to have different bindings. I'm not sure if that's the only difference between case and is, though.
@alrz I think I understand the reasoning, but can you please demonstrate a case when ordinary is expression will be broken if binding would prefer ClassVsProp type instead of ClassVsProp member?
Is far as I understand the problem, we should talk not about "defaults to types"/"defaults to constants", but on binding of ClassVsProp name to type or member. Right now in is expression C# defaults to member, however it looks like this is not useful for constant patterns at all, since you can't reference constants through instance qualifier
@controlflow Oh, I see. That seems like an unhandled Color Color case.
Could you please post a snippet of code generating a ConstantPatternSyntax?
I tried with the samples here and the Color-Color but I can't see it in the Syntax Visualizer.
if (i is 3) produces a constant pattern
Easier than every snipped I tried :D
Thank you!
Most helpful comment
@controlflow Oh, I see. That seems like an unhandled Color Color case.