3 ms·

Ugh. So with the new method groups feature, adding a new method overload can break working code even if that code never calls the new overload.

• nick_ 5y ago
  Changing the code changes the code. In any popular language, if you have some method whose single argument is being implicitly upcast by a caller then you add a more specific overload on that arguments inheritance hierarchy, the caller will now be calling the new method.
• moron4hire 5y ago
  That was already the case. This does not change that issue. Using the example of Console.Read from the article, in C# 9, you could do `Func<int> read = Console.Read;`. Now, if someone adds an overload for the Read method to Console, that C# 9 code will break. In C# 10, that doesn't change. What changes is that we don't have to specify `Func<int>`. We can just use `var`.
  • nick_ 5y ago
    That's right. Additionally, this worked back to C# 4 or 5, I think?
  • int_19h 5y ago
    You wouldn't even have to get lambdas involved for this problem to surface. Consider something like this: void Foo(double x) { ... } Foo(123); This works, but now I add an overload: void Foo(decimal x) { ... } and the above call is now ambiguous. Note that this example goes all the way back to C# 1.0! Method overloading (and how it interacts with other language features) is probably the single most complicated part of C# today, for good reasons.