Adding an implicit long operator seem to break the switch case pattern

[wiz0u]

When you uncomment the implicit operator, the compiler fails on the switch case Derived* pattern matching lines, stating that b is an expression of type 'long'

This seems wrong to me.

namespace Test
{
	class Base
	{
		// uncomment this and it breaks the switch case
		//public static implicit operator long(Base b) => 0;
	}

	class Derived1 : Base { }
	class Derived2 : Base { }

	class Program
	{
		static void Main()
		{
			Base b = new Derived1();
			switch (b)
			{
				case Derived1: break;
				case Derived2: break;
			}
		}
	}
}

Tested with LangVersion latest, up-to-date VS

[wiz0u]

The line

if (b is Derived2 d) ;

would compile fine however, so not all pattern matching is broken, just in switch

[SSM240]

This seems to be intended behavior according to section 13.8.3 of the spec:

The governing type of a switch statement is established by the switch expression.

• If the type of the switch expression is sbyte, byte, short, ushort, int, uint, long, ulong, char, bool, string, or an enum_type, or if it is the nullable value type corresponding to one of these types, then that is the governing type of the switch statement.
• Otherwise, if exactly one user-defined implicit conversion exists from the type of the switch expression to one of the following possible governing types: sbyte, byte, short, ushort, int, uint, long, ulong, char, string, or, a nullable value type corresponding to one of those types, then the converted type is the governing type of the switch statement.
• Otherwise, the governing type of the switch statement is the type of the switch expression. It is an error if no such type exists.

So if the type of the expression inside the switch statement is implicitly convertible to exactly one of those types, then the overall type of the switch statement will always be that converted type, causing type pattern matches to fail. This also means if you define more than one of those implicit conversions (such as also adding an int conversion), then it doesn't try to use any of the conversions and your example works again. (The Derived classes don't really impact the situation - there's a simpler example with only one class here.)

You could imagine it falling back to using the directly given type if treating it as the converted type fails, but I assume it's undesirable for specific cases to be able to impact the overall governing type of the switch statement. I also can't speak to why exactly it automatically converts the type like this to begin with. My best guess is that most cases of a type implementing exactly one implicit conversion, and no more, are wrapper types that are meant to be more or less equivalent to that type and wouldn't have derived types (so no need to try to match on type), in which case that conversion is not only fine, but perhaps desirable for performance reasons? That's all speculation, though. (EDIT: actually I'm pretty sure it's just backwards compat stuff, see below)

[siegfriedpammer]

This seems to be one of the downsides of reusing the switch syntax for type pattern matching. The existing input types have precedence over newer features, as existing code should not change its meaning.

Probably this would need some form of target-typing from the switch sections/arms.

[SSM240]

Ah, yeah, I think the conversion behavior probably is just for backwards compatibility. Switch statements used to be restricted to primitive types, but you could also use types that were implicitly convertible to them - which means that even after switch statements were expanded to allow more types in C# 7.0, the existing type conversion behavior still had to be preserved. Gotta love fun gotchas in the name of backward compatibility :p