5

Why is this allowed?

private void foo(int x, int y, int z = 0) { MessageBox.Show("A"); }
private void foo(int x, int y) { MessageBox.Show("B"); }

...and what is the reasoning behind the designers of C# deciding upon "B", should you attempt to foo(0,0);?

Soner Gönül
  • 97,193
  • 102
  • 206
  • 364
KatDevsGames
  • 1,109
  • 10
  • 21
  • 3
    Bear in mind that this allows people to hide a partial class in another file that steals your function calls! – KatDevsGames Aug 20 '14 at 06:18
  • 6
    Having decided to allow default parameters to be added to the language, and having decided on a clear set of rules for how to deal with overloads and default parameters, the question is, why should the compiler have to have *more* complexity to tell you "no, you're wrong" here? No feature is free, even an error message. Also, you shouldn't ever have to directly comment on your own questions, as you have here - if you have more to add, please use the `edit` link at the bottom of your question. – Damien_The_Unbeliever Aug 20 '14 at 06:22
  • @Dirk, Good catch on the duplicate. That was not obvious. – merlin2011 Aug 20 '14 at 06:25
  • Definitely a good catch on the duplicate. I was just about to post the same thing as the answer to that question. :-) – Cody Gray - on strike Aug 20 '14 at 06:26
  • 1
    @Damien_The_Unbeliever It's true that no feature is free, but this does seem a little poorly thought out. The above creates a situation where the default value on the first `foo` is completely useless. Regarding 'why should the compiler have to have more complexity to tell you "no, you're wrong" here?', I think it might have been wiser to define the feature in such a way that the example above is not legal, and then the answer to your question would be "because detecting syntax errors is the compiler's responsibility." – JLRishe Aug 20 '14 at 06:35
  • @JLRishe - in the one circumstance where you have two identical method signatures except that one of them has exactly *one* additional parameter which is default, you get this situation where the one with the default parameter isn't conventionally callable. But consider if the first method had more than one default parameter - then both methods are callable in a sane fashion, including making use of (some of) the defaults. So you would have to special case this conflict where there's only one extra parameter. – Damien_The_Unbeliever Aug 20 '14 at 06:43
  • 1
    @Damien_The_Unbeliever Yes, I realize that It's only applicable for the case where all parameters are the same except for a single default parameter. But that still seems like it might be relevant enough to merit restricting it. Or on the other hand, they could have simply forbade method invocations that are ambiguous on account of default parameters. After all, the compiler restricts ambiguous calls when default parameters aren't involved. I guess there could be some obscure scenarios that take advantage of this ambiguity resolution, but it seems like a breeding ground for insidious bugs. – JLRishe Aug 20 '14 at 07:08
  • It's most certainly relevant enough to merit restricting it. Simplicity is good when you have it but simplicity alone does not make a design good. This is exactly the sort of thing that can cause, as JLRishe put it, "insidious bugs". It's also a potential security problem. I can see this being the exact sort of thing that could be exploited by an insider for the purposes corporate espionage. – KatDevsGames Sep 20 '14 at 19:39

0 Answers0