问题
In the Roslyn Pattern Matching spec it states that:
The scope of a pattern variable is as follows:
If the pattern appears in the condition of an if statement, its scope is the condition and controlled statement of the if statement, but not its else clause.
However the latest Microsoft "What's new" posts and presentations are showing this example:
public void PrintStars(object o)
{
if (o is null) return; // constant pattern "null"
if (!(o is int i)) return; // type pattern "int i"
WriteLine(new string('*', i));
}
Which shows the pattern match i variable used outside the if level scope of the pattern match.
Is this an oversight, or has the scoping been changed from the spec?
回答1:
I posted a similar question to the Roslyn issues and was given the answer by DavidArno:
It's long, but you can read all the gory details of why the language design team chose to "enhance" the language in this way at #12939.
TL;DR you aren't alone in thinking the change unintuitive and contradictory to the way scope have worked before. The team sadly don't care though and the change is here to stay.
It seems the decision was made that this scoping would apply, so the spec is now out of date, and this scoping is sadly here to stay:
Option 3: Expression variables are scoped by blocks, for, foreach and using statements, as well as all embedded statements:
What is meant by an embedded statement here, is one that is used as a nested statement in another statement - except inside a block. Thus the branches of an if statement, the bodies of while, foreach, etc. would all be considered embedded.
The consequence is that variables would always escape the condition of an if, but never its branches. It's as if you put curlies in all the places you were "supposed to".
Conclusion
While a little subtle, we will adopt option 3. It strikes a good balance:
It enables key scenarios, including out vars for non-Try methods, as well as patterns and out vars in bouncer if-statements. It doesn't lead to egregious and counter-intuitive multi-level "spilling". It does mean that you will get more variables in scope than the current restrictive regime. This does not seem dangerous, because definite assignment analysis will prevent uninitialized use. However, it prevents the variable names from being reused, and leads to more names showing in completion lists. This seems like a reasonable tradeoff.
回答2:
From that same documentation:
the variables introduced by a pattern – are similar to the out variables described earlier
So actually this code:
if (!(o is int i)) return; // type pattern "int i"
Is more or less equal to:
int i;
if (!(SomeParsingOn(o, out i))) return; // type pattern "int i"
That means that i is declared on the same level as the if, which means it is in scope not only for the if, but also for following statements. That this is true can be seens when you copy the if:
if (!(o is int i)) return; // type pattern "int i"
if (!(o is int i)) return; // type pattern "int i"
Gives error CS0128: A local variable named 'i' is already defined in this scope.
来源：https://stackoverflow.com/questions/40680781/pattern-match-variable-scope