Annoying scope of pattern matching variables

[TactiTac0z]

Do we currently have an active issue that tracks improving the scope of pattern matching variables?
Like for cases like this.

var value = ...;

if (value is SomeType obj)
{
  ...
}
if (value is SomeOtherType obj) // compiler error, variable obj is already declared
{
  ...
}

var obj = ...; // compiler error again

This seems quite silly especially given pattern matching variable can't be used unless the expression definitively return true anyway

if (value is SomeType obj)
{
  ...
}

return obj; // compiler error, obj may not be assigned here. Why do we extend the scope of pattern matching variables this wide when they can't be used outside in this case anyway?

To say it simply, pattern matching variable scope should be equal to where that variable is definitively assigned.

the alternative to the above would have been naming the variables obj, obj2 and obj3 which is annoying

[HaloFour]

This behavior is quite intentional and the result of a lot of discussions regarding the scenarios supported by different scoping rules for pattern variables. There are probably numerous meeting notes on the subject, but I believe this is where "leaky scope" was introduced:

https://github.com/dotnet/csharplang/blob/main/meetings/2016/LDM-2016-07-15.md
dotnet/roslyn#12939

I believe there was some degree of interest in perhaps permitting shadowing the variables in those scopes where the existing variable was not definitely assigned, or maybe exploring "flow scoping" (which is what you described, and how Java approached pattern variables), but I don't believe either conversation has gone anywhere.

[ufcpp]

I have many codes like following:

if (nullableValue is not { } value) return;
value = ...

[DavidArno]

I have many codes like following:

if (nullableValue is not { } value) return;

value = ...

Genuinely, why? Maybe the terseness of your example hides a detail in real use cases, but what purpose is value if the if expression if you immediately overwrite it?

[TactiTac0z]

I have many codes like following:

if (nullableValue is not { } value) return;
value = ...

Fair enough. The allowing shadowing when not definitively assigned would be fine for me that wouldn't break anything. I wonder if anyone can see any objections for that.

[ufcpp]

Early return on a variable is not match.
Other than null (not {}), I have many early returns, for example:

if (x is not T t) return;
if  (x is not [var first, ...]) return;
if (x is not T { Success: true } t) return;

[ufcpp]

is null early return can be tedious when it comes to nullable value types.

foreach (var nullableValue in nullableValues)
{
    if (nullableValue is not { } value) continue;

    // or
    //if (!(nullableValue is { } value)) continue;

    // instead of:
    //if (nullableValue is null) continue;
    //var value = nullableValue.GetValueOrDefault(); // tedious!!

[333fred]

Related to #8622, though more liberal than that proposal allows.

[TactiTac0z]

Hey thanks @333fred.
I see the bot limited engagement in that issue I assume because you started to change the flags on it, what does that usually mean?

[333fred]

See the new process detailed here: https://github.com/dotnet/csharplang/blob/main/Design-Process.md. All champion issues are locked to ensure that discussion stays in discussion.

[BlinD-HuNTeR]

the alternative to the above would have been naming the variables obj, obj2 and obj3 which is annoying

Actually, there is another alternative, you can just introduce nested scopes (although this may also be annoying):

{
  if (value is SomeType obj)
  {
    ...
  }
}
{
  if (value is SomeOtherType obj) // it's not an error now.
  {
    ...
  }
}

To say it simply, pattern matching variable scope should be equal to where that variable is definitively assigned.

If this is implemented then it would actually prevent #8622 completely, because that proposal is all about "reusing a pattern variable in a different branch".

[TactiTac0z]

the alternative to the above would have been naming the variables obj, obj2 and obj3 which is annoying

Actually, there is another alternative, you can just introduce nested scopes (although this may also be annoying):

{
  if (value is SomeType obj)
  {
    ...
  }
}
{
  if (value is SomeOtherType obj) // it's not an error now.
  {
    ...
  }
}

To say it simply, pattern matching variable scope should be equal to where that variable is definitively assigned.

If this is implemented then it would actually prevent #8622 completely, because that proposal is all about "reusing a pattern variable in a different branch".
@BlinD-HuNTeR

Yeah I am aware of this. But it almost needs if (true) or // scope infront to make it clear block without a flow control keyword is on purpose imo so I would rather do it numbered, you would also have to do return or goto if you want else if like behavior