if (!(o is int i)) return; // type pattern "int i"
    WriteLine(new string('*', i));

Mads Torgersen — MSFT:
The `operator is` was an earlier proposed syntax for what eventually became the `Deconstruct` method. They serve the same purpose, which is to describe how an object is deconstructed, and both have potential to grow more expressive as C# evolves (to allow something like F#’s “active patterns”, for example).

Deconstruction does not yet work in patterns. We hope to get to that soon, but not in C# 7.0. In general, think of patterns as a new concept that has taken root in the language and can evolve over time.

The tentative plan is to use the same scoping rules as for pattern variables, which could be found here https://github.com/dotnet/roslyn/blob/features/outvar/docs/features/patterns.md

int x;
if (dict.TryGetValue(someKey, out x)) ...
...

S>Ну и кого новая переменная после return волновать будет? Если в коде простынка такого размера, что out var незаметен, то проблема не в самой out var как бы.

S>int x;
S>if (dict.TryGetValue(someKey, out x)) ...
S>...
S>

 if (true || dict.TryGetValue(someKey, out var x))
 {
// А чему будет равен x здесь? 
 }

// UPD, out _var_ в вызовах забыл. Fixed.
bool CheckSomething(int x) => TryGet1(x, out var y) && TryGet2(x, out var z) && Check(y, z);

int x;
if (true || dict.TryGetValue(someKey, out var x))
{
   // А чему будет равен x здесь? 
}

>My thoughts are a bit different. It looks like that C# is becoming polluted with all kinds of tricks. I’m afraid that this could lead to a big ball of mud ...

Mads Torgersen — MSFT
You hit on something very central to language evolution. We can add, but we can never take away. This weighs heavily on our minds as we evolve C#. Anders famously says that “every feature starts with minus a hundred points”. For every feature we try to think about whether people will appreciate it not only now, but ten years from now. We try to think about whether it’s worth not only the work involved today, but the space it will forever occupy in the language surface area.

We’re often right, but not always. As you know, the future is one of the hardest things to predict. 😉 And this brings us to another aspect of our design approach: we need to be bold. We need to not be stymied by our responsibility to a distant future. Because otherwise we won’t have that future. C# needs to be among the greatest programming languages today, or it won’t be among them tomorrow.

So we do add things pretty aggressively. We try to add the most valuable features to developers. Moreover we try to add them in a way the minimizes the “agin” of the language in terms of added complexity. Yes, pattern matching is a new feature, but it works in existing constructs such as “is” and “switch”, and over the existing kinds of types. It is (hopefully) well-integrated with our past. At the same time, it introduces patterns in a way that leaves lots of room for them to grow as a concept, without that generality introducing a tax today. It is well-integrated with our plausible future.

You won’t believe how much time we’ve spent speculatively designing the possible futures of patterns, just so that we could make sure to remain open to them. This is part of how we try to keep the language’s long term health and viability at heart as we add new features.

I hope that helps give a picture of how we think about the long term evolution of C#?

var someCoeff = 2;

int MultiplyByCoeff(int x) => someCoeff * x;

Console.WriteLine($"coeff = {someCoeff}, MultiplyByCoeff(10) = {MultiplyByCoeff(10)}");