[klodolph]

I’m not making any claims about function overloading in general. Only C#.

It interacts in surprisingly complicated ways with a surprising number of other parts of the language. It causes problems with prospective new features. IIRC there have been a number of bugs in the spec and in the compiler wrt overloading. Given the overall high level of expertise of people working on the spec I would say it’s a bit of a minefield, compared to the rest of the language.

Edit: Found a Q&A by John Skeet, https://youtu.be/8UvTdobOiJk?t=1292

“Overload resolution is the nexus that every feature ends up contributing to. […] All of these things make overload resolution and type interface really really really complex and it’s always a bit of the C# specification that I found hardest to understand […] and it turns out so did the spec designers, because they got it wrong, and we’ve been trying to fix it.”

[OskarS]

It might be tricky from a standards point of view, but as a user of the language, I don't think I've ever had an issue with how it handles overload resolution. Every once in a while you get an "call is ambiguous" compiler error, but I've always found the "ambiguity" to be reasonable and easy enough to fix (by making generics explicit or using an explicit cast). It's also a very minor bummer that you can't overload on return type, but that is A LOT to ask of a language.

Generally speaking, I've found C# to be a very pleasant language to work in, by far my favorite in that particular "lane" of computer languages (i.e. annoyingly object-oriented enterprise languages, like C#, Java or C++).

[lsadam0]

Thanks for the detailed reply. There’s lots here I had not considered. I’ve realized my overloading implementations have been rather simple cases.