[quotemstr]

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.

[moron4hire]

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`.

[int_19h]

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.

[nick_]

That's right. Additionally, this worked back to C# 4 or 5, I think?

[nick_]

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.