模式匹配变量范围 [英] Pattern match variable scope

问题描述

在Roslyn模式匹配规范指出:

模式变量的范围如下:

The scope of a pattern variable is as follows:

如果模式在if语句的条件下出现，则其范围是if语句的条件和受控语句，但不是其else子句.

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.

但是最新的Microsoft新功能" 帖子和演示文稿显示了以下示例:

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));
}

其中显示了在模式匹配的if级别范围之外使用的模式匹配 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?

推荐答案

我发布了类似的问题解决罗斯林问题，并由 DavidArno 给出了答案:

I posted a similar question to the Roslyn issues and was given the answer by DavidArno:

很长，但是您可以阅读有关为什么使用该语言的所有细节的信息设计团队选择通过#12939 以此方式增强"该语言.

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您并不孤单地认为变革是非直觉的，与范围以前的工作方式矛盾.团队可悲的是不在乎，更改将保留在那里.

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:

选项3:表达式变量的作用域是for，foreach和using语句以及所有嵌入式语句:

Option 3: Expression variables are scoped by blocks, for, foreach and using statements, as well as all embedded statements:

这里的嵌入式语句意味着什么，它被用作另一个语句中的嵌套语句-块内除外.因此if语句的分支，while的主体，foreach等.都会被认为是嵌入式的.

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".

结论

虽然有些微妙，但我们将采用选项3.余额:

While a little subtle, we will adopt option 3. It strikes a good balance:

它启用关键方案，包括用于非Try方法的变量，如以及保镖if语句中的模式和out var.不会导致极端和违反直觉的多层次溢出".它确实意味着您将获得比当前更多的范围变量限制性制度.这似乎并不危险，因为分配分析将防止未初始化的使用.但是，防止变量名被重用，并导致更多名称显示在完成列表中.这似乎是一个合理的权衡.

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.

这篇关于模式匹配变量范围的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！