Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 7383 [details]
Simple program illustrating ambiguous call
1. Compile attached program
The application should not compile (or at the very least a warning should be emitted) due to the ambiguous method call
Compilation succeeds without error and no warnings!
I also tested in Microsoft Visual Studio 2012 and it doesn't emit a warning or fail to compile either which surprised me.
The basic essence of the issue is calling a method like this...
with the following methods defined
public static void foo(int a, bool c=true)
public static void foo(int a, bool b, bool c=true)
is ambiguous to the developer (I don't know if it is ambiguous in the C# language specification).
The call is not ambiguous according to C# overloading resolution rules specification
> The call is not ambiguous according to C# overloading resolution rules
I just had a quick look at the spec and I assume you're referring to
From 220.127.116.11 Better function member
Otherwise if all parameters of MP have a corresponding argument whereas default arguments need to be substituted for at least one optional parameter in MQ then MP is better than MQ.
Be that as it may I think emitting a warning would be useful because most developers are not going to be experts in the overloading rules in the language specification. A warning could easily be silenced by rewriting the call as
foo(5, true, true)
depending on which method the developer actually wants to call.
That's not going to happen. C# developers should know rules of the language and if the they are not sure then check the spec. Issuing warning would break compatibility with csc and still not address the issue as same rules are used in other contexts like type inference, etc.
Okay it's a WONTFIX then.