Breaking changes in C# 10

[sakno]

C# 10 introduces lambda type inference which is breaking change in my case. My library has the following methods:

void Method(Action action);
void Method(Expression expr);

Prior to C# 10 the consumer has no problem when invoking Method(() => DoSomething()). But now the delegate type must be explicitly defined: Method((Action)() => DoSomething()). Otherwise, the compilation process stopped with error CS0121: The call is ambiguous

[Joe4evr]

This is already known to the language team.

[CyrusNajmabadi]

FWIW, i would like us to revisit: The DoAction(Expression) method is applicable, even if it has errors, in the future. I think for lambdas it's a bit nonsensical. We already understand for normal overload resolution "oh, this takes a string, but you passed an object, so that's an error, so don't consider this". In think lambda+expression or lambda+delegatetype needs something similar. We can see it, and try it out. But if it's an error, then it should not count and we should keep looking.

I get that that's not what we do today. But, IMO, that's fairly unintuitive and leads to these undesirable situations. When you have instance+extension for me, the intuition should be "use the instance if it works, otherwise fallback and look at extensions". It shouldn't be "oh, you found a non-functional instance? well we're going to use that, despite us knowing it definitely does not work". That just seems 'broken' to me :)

[sakno]

Let's do a small recap. What I should expect from .NET 6? Will this resolution between extension and instance method be solved? If no, I have to inform the users of my library that their code might be broken. If so, I need to be prepared for negative feedback. According to my experience, most users recognize that all negative impact caused by breaking changes in .NET must be eliminated by the library author somehow. In other words, when the choice library vs BCL happens, the last one treated as ultimate source of truth.

The DoAction(Expression) method is applicable, even if it has errors, in the future.

When to expect this future?

[CyrusNajmabadi]

When to expect this future?

We'd need a proposal, a champion, a spec for how this would work, approval by ldm, and enough time in a future release cycle to do this work. Currently absolutely no steps have been taken here, so I can't even give any sort of estimate on when this could be expected

[CyrusNajmabadi]

Will this resolution between extension and instance method be solved?

It has been solved in that we are accepting and documenting the breaking change in behavior.

Existing users of your library who do not recompile will continue having binary compat with your lib. To help users who do recompile, you can add an instance method to the type instead of having it be an extension method.

[CyrusNajmabadi]

In other words, when the choice library vs BCL happens, the last one treated as ultimate source of truth.

Yes. We are never happy about breaking changes. However, in this case we think the net benefit is high enough for most users and libraries to make this worthwhile. Omelettes and eggs and all that.