Block-scoped type narrowing with the is operator

[BalassaMarton]

I'm not sure how to call this, or if this has been requested before, so I'm not marking it as a proposal yet.
Basically, I want to be able to do what I can in TypeScript with type guards:
Instead of

object greeting = "Hello, World!";
if (greeting is string message)
{
    Console.WriteLine(message.ToLower());  // output: hello, world!
}

I should be able to just write this, since the compiler can already narrow the type of greeting inside the block:

object greeting = "Hello, World!";
if (greeting is string)
{
    Console.WriteLine(greeting.ToLower());  // output: hello, world!
}

Similarly, this should work:

object greeting = "Hello, World!";
if (greeting is not string) return;
Console.WriteLine(message.ToLower());  // output: hello, world!

The compiler already does something similar when it applies nullability constraints, so this doesn't seem like a far-fetched idea, and it fits into the language nicely, no new keyword or alien syntax would be necessary.

[timcassell]

While this isn't strictly about generics, this looks like it would be similarly solved by generic bridges (#6308).

[Edit] Or maybe not, since you're checking the instance type rather than a static type.

[HaloFour]

Unfortunately this would break existing code as if the type of the variable changes within a scope then all method resolution within that scope is impacted.

[BalassaMarton]

Can you show a code snippet that would break if it were just behaving like TypeScript.

[HaloFour]

void M(object o) => Console.WriteLine(1);
void M(string s) => Console.WriteLine(2);

object o = ...;
if (o is string) {
    M(o); // prints 1
}

TypeScript is an extremely different language, as Javascript has no concept of compile-time types and all dispatch is done dynamically at runtime. That is not the case in C#, which is statically typed and overload resolution is done at compile time.

[BalassaMarton]

But that's not existing code that could break, and if you add this feature, it would mean that as long as the compiler is sure that a variable is assignable to a concrete type, it will treat it as such, so in the above example, it would print 2. But I've found a case when it's really ambiguous, and it's when you narrow the type a second type, but the new type is not assignable to the first one:

void M(object o) => Console.WriteLine(1);
void M(IEnumerable<object> e) => Console.WriteLine(2);
void M(IDisposable d) => Console.WriteLine(3);

object o = ...;
if (o is IEnumerable<object>) {
    M(o); // prints 2 because that's the most specific overload
    if (o is IDisposable) {
        M(o); // ???
    }
}

The rules of type inference in situations like this is up to the new specification, it can be the innermost type, the most derived type (when the inner type is assignable to the outer one), or a compile-time error.

[HaloFour]

But that's not existing code that could break

That code has always been legal, since C# 1.0. So has yours.

it would mean that as long as the compiler is sure that a variable is assignable to a concrete type, it will treat it as such, so in the above example, it would print 2

That would be a massive breaking change to the language. Both in my example and yours the code must print 1. There is no ambiguity, o is an object and will always be an object. C# doesn't reinterpret variable types based on flow analysis.

[BalassaMarton]

OMG I'm such an idiot. Couldn't see the forest from the tree.

[miyu]

There are ways to work around breaking existing code. For example:

if (o is narrowed to string) Console.WriteLine(o.ToLower());
if (o is string o) Console.WriteLine(o.ToLower());

This thread seems related to #6308... there you'll see examples like:

public static bool TryParse<T>(this string? s, IFormatProvider? provider, out T? value)
{
    // New code: Shortcut if T is IParseable<T> (now illegal because T is a type, not an instance):
    if (T is IParseable<T> TParseable) // TParseable is a constrained type argument now
        return TParseable.TryParse(s, provider, out value);

    // Original code: trying to use TypeConverters as fallback etc...
}

[HaloFour]

There are ways to work around breaking existing code. For example:

if (o is narrowed to string) Console.WriteLine(o.ToLower());
if (o is string o) Console.WriteLine(o.ToLower());

Or the following, which is already perfectly legal:

if (o is string s) Console.WriteLine(s.ToLower());

This thread seems related to #6308... there you'll see examples like:

Not really. That applies to generic type parameters themselves. It's different enough that it's mentioned why it doesn't make sense for the syntax to resemble a normal if statement.

[miyu]

I agree that if you're working with one-char variables swapping o to s is usually somewhat acceptable - you're still polluting your scope, but that's typically manageable.

The benefit of narrowed typing would be more apparent in real-world scenarios where you'd typically end up having more verbose redundancy like someVariableName and ``someVariableNameAsStr`. For example:

switch (inboundMessage) {
  case SomeSpecificMessageType someSpecificMessageType: /* logic */ break;
  case SomeOtherSpecificMessageType someOtherSpecificMessageType: /* logic */ break;
  /* add N more cases */
}

Or I guess, in if form as pertinent to this discussion

if (inboundMessage is SomeSpecificMessageType someSpecificMessageType) {
  /* logic */
} else if (inboundMessage is SomeOtherSpecificMessageType someOtherSpecificMessageType) {
  /* logic */
} else /* add N more cases */

In the contrived OP gave, they've awkwardly aliased greeting as message which actually has made their code more confusing - there are now more variables to reason about within a scope. That's a common pitfall of the current workarounds. The alternative in their code would have been greetingStr as I've exemplified above.

[HaloFour]

You can already give each pattern variable in a switch the same name as each case has narrow scoping, so there is no overlap:

object x = ...;
switch (x) {
    case string y:
        break;
    case int y:
        break;
}

That's not possible with if due to the leakiness of the scoping there. You can use blocks to narrow the scope, but that's also kludgy. You wouldn't be able to reuse the identifier short of applying some kind of shadowing, which C# has generally shied away from. I recall a conversation about allowing shadowing in cases where the identifier was not definitely assigned (and thus couldn't be used directly anyway), but I kind of doubt it would ever bubble up to the level of being worth doing. Afterall, names are cheap.

[BalassaMarton]

In the contrived OP gave, they've awkwardly aliased greeting as message which actually has made their code more confusing

I copied that code from the official docs 😄