[Proposal]: [is-inference scope]

[mauler2025]

The Play method defined in Child should be available from Parent variable p pointing to a Child object in a scope where p has passed the condition if(p is Child) below.

class Parent{}
class Child : Parent
{
    void Play() { }
}

class Program
{
    static void Main()
    {   
        Parent p = new Child();
        if(p is Child)
        {
            p.Play();
        }
    }
}

I am inspired by the Dart language! Any comments are always welcome.

[mauler2025]

Someone with the following statements asked me to reopen this.

"Smart casts might pose a much more convenient feature than introducing new variables with the new type, it would also avoid redundancy or noise in many cases.
The compiler could simply translate the normal instance-of check to a pattern variable if necessary."

[leandromoh]

I think is more readable with a new variable...

if (p is Child c)
{
    c.Play();
}

[HaloFour]

The language can't reinterpret p to be a Child without introducing breaking changes as Parent can already have a non-virtual method called Play.

[artelk]

It could be allowed to redeclare the variable p:

if (p is Child p) // also p
{
    p.Play();
}

I think that is backward compatible and safe as the p inside the block is still the same instance.

[HaloFour]

Or you can use a new identifier, which is already legal and is more clear.

if (p is Child c)
{
    c.Play();
}

[artelk]

From my point of view this is less clear. It requires you to invent a new name for the same object. Looking into the nested block of code (which can be longer) you will need to answer questions like "is c the same object as my p or I'm calling methods on some other instance?" There are other modern languages like Rust and Kotlin that allow you even more and you can redeclare the variable just everywhere (https://blog.allegro.tech/2018/05/From-Java-to-Kotlin-and-Back-Again.html#name-shadowing). And their authors also intended to make things more clear. Of course every language feature can be misused. In this case the compiler can warn if you give the same name but the instance/object identity is different.

[HaloFour]

It requires you to invent a new name for the same object.

Names are cheap. In this case calling it a p as an abbreviation of Child makes a lot less sense, and that's often the case when comparing the type, it recontextualizes the variable and more often than not a new identifier will much more clearly state what it is. The reference isn't as relevant as the type.

There are other modern languages like Rust and Kotlin that allow you even more and you can redeclare the variable just everywhere

Those languages were designed to behave that way from their onset. C# was not, and there are 20 years worth of C# code that was written to not expect this behavior. Reinterpreting the variable implicitly won't be on the table. Shadowing might be a different conversation, but C# explicitly did not incorporate implicit shadowing behavior from C++ because it was well known that having multiple identifiers of different types sharing the same name with overlapping scopes is a source of bugs.

[theunrepentantgeek]

because it was well known that having multiple identifiers of different types sharing the same name with overlapping scopes is a source of bugs.

From my recent experiences working on a Go project with others, I can testify this is still very true. We've even considered introducing a third-party linter to catch shadowing for non-error locals.

[333fred]

As this is not a full syntactic and semantic proposal, I'm converting it to a discussion.

[ZacharyPatten]

As @HaloFour mentioned this would be a breaking change. Here is why:

In example 0 below, your feature request would be unable to determine which Value to call. The one on A or the one on B?

Also, examples 1 and 2 while not breaking changes are reasons alone this feature should not be considered.

using System;
using System.Collections.Generic;
using System.Text;

class Program
{
	static void Main()
	{
		// 0. your issue would break existing code, such as with "new" members
		A a = new B();
		if (a is B)
		{
			// Which "Value" would it call? A or B? you proposal would break this.
			Console.WriteLine($"Your proposale would break \".Value\"...");
			Console.WriteLine($"Can't determine: {{ A = {a.Value} }} or {{ B = {(a as B).Value} }}");
		}

		// 1. multiple "is" operators on the same variable would break your issue
		// and result code that should not compile, or behave differently based
		// on the number of "is" operators in the condition
		if (a is int && a is string && a is StringBuilder && a is List<int>)
		{
			a++;                            // int
			a.Replace("a", "has");          // string
			a.Append("an identity crysis"); // StringBuilder
			a.Add(0);                       // List<int>
		}

		// 2. storing the condition in a variable would not be supported
		bool condition = a is StringBuilder;
		if (condition)
		{
			((object)a as StringBuilder).Append("a reaches for a bottle of Clorox");
		}
	}
}

public class A { public int Value => -1; }
public class B : A { public new int Value => -2; }

[DaZombieKiller]

Just spitballing, but could that be mitigated by allowing a is B a? I don't think that code would compile today, so it would avoid a breaking change.

class Parent
{
    public void Play() {}
}

class Child : Parent
{
    public new void Play() {}
}

class Program
{
    static void Main()
    {
        Parent p = new Child();
        
        // p is treated as a Child instance within this block
        if (p is Child p)
            p.Play(); // Calls Child.Play
        
        // From here onwards, p is now treated as Parent again
        p.Play(); // Calls Parent.Play
    }
}

[Joe4evr]

That won't work because of the leaky variable scope.

[DaZombieKiller]

It probably wasn't very clear in the example, but I was intending it to be a special case where it doesn't declare a new variable but instead changes the type within the scope of the if. There are several things that this can be argued against with though, namely consistency and the fact that renaming the variable will change behaviour of the code.