Odious ambiguous overloads, part two

В Инфуфа веруем: диалог

Блог Эрика Липперта (перевод) — Wed, 03 Jun 2009 23:58:43 GMT

Пользователь: Оператор typeof(T) в C#, по существу, означает «компилятор, сгенерируй некий код, который

In Foof We Trust: A Dialogue

Fabulous Adventures In Coding — Fri, 22 May 2009 20:43:37 GMT

User : The typeof(T) operator in C# essentially means “compiler, generate some code that gives me an

Future Breaking Changes, Part One

Fabulous Adventures In Coding — Fri, 07 Sep 2007 01:23:48 GMT

We on the C# team hate making breaking changes. As my colleague Neal called out in his article on the

re: Odious ambiguous overloads, part two

TheMuuj — Sat, 28 Oct 2006 04:01:22 GMT

While it would be a hideous hack, you could always add an attribute that controls the order in which the metadata is emitted by the compiler.

I believe there are some source-order dependencies in C# with regards to field initializers. If you have source-code rules about which order members of a class should appear (alphabetical, for instance) this could be a minor problem.

An attribute that takes an integer parameter could fix these problems.

But like I said, it'd be a hideous hack.

The current behavior needs to be documented and maybe even added to the spec so that other CLR implementations can be compatible.

re: Odious ambiguous overloads, part two

Jeroen Frijters — Fri, 07 Apr 2006 14:18:15 GMT

One way to disambiguate the interface methods would be to add a modopt to the generic type parameters in the method signature of methods that potentailly clash.

I don't think it is a realistic solution, because it would complicate (and break) cross language and cross version scenarios, but it is something worth mentioning.

re: Odious ambiguous overloads, part two

Kyle Lahnakoski — Fri, 07 Apr 2006 03:18:31 GMT

> It could be an error to have any explicit implementation of an interface method which matches ambiguously. > This would be a smaller breaking change, but still breaking.

I would imagine that the number of explicite implementaions like I1<int> would be rare, if not non-existent.

What do any of these breaking changes buy the user though? Not more functionality, but less. Basically we'd be saying "you could do th> It could be an error to have any explicit implementation of an interface method which
> matches ambiguously. This would be a smaller breaking change, but still breaking.

I would imagine that the number of explicit ambiguous implementations (like I1<int>) would be rare, if not non-existent. Is there much in the C# libraries that breaks with this “functionality” is denied?

> What do any of these breaking changes buy the user though? Not more functionality,
> but less. Basically we'd be saying "you could do this before, and now you can't, too bad."
> That's a hard sell.

Functionality and clarity are a balancing act. Personally, I would categorize this “functionality” as a “gotcha”. It would be crazy-hard to debug such a thing, especially if the implementations are in parent classes, and especially if you are not aware that such craziness could happen. At least the warning you propose indicates a possible random behavior.
is before, and now you can't, too bad." That's a hard sell.

re: Odious ambiguous overloads, part two

Eric Lippert — Fri, 07 Apr 2006 02:15:15 GMT

Sure, we'll have a talk with the CLR folks and see if a future version of the CLR can get this feature added.

And no, of course I didn't decide this by myself! I wrote a detailed analysis of the bug and sent it off to Anders and Mads and Don Box and a whole pile of other people who are part of the standardization process, and took guidance from them. And the guidance was that if possible, the standard and implementation should be emended to read that unification is dejure, and if not, we'll issue a warning and stay broken until it is practical to fix the problem. There's absolutely no point in changing the standard if it's _impossible_ for the implementation to comply! It's better to just leave it implementation-defined behaviour in this regrettable scenario.

re: Odious ambiguous overloads, part two

James Mastros — Fri, 07 Apr 2006 00:29:02 GMT

Er, you really mean that you added a warning, and pushed a request to be able to tell them apart to the CLR metadata folks, because sometimes all you can do is add a warning, and push it to the guys who can really fix it, right?

Or did you just add a warning, and mark the bug FIXED when it isn't really?

re: Odious ambiguous overloads, part two

James — Thu, 06 Apr 2006 22:49:35 GMT

I'm intrigued - did you decide what to do by yourself, or solicit guidance from your ECMA buddies? C# is a standard, you know. Is it fair to just do your own thing then run it through the process afterwards?