http://d.puremagic.com/issues/show_bug.cgi?id=9999
--- Comment #1 from Kenji Hara <k.hara...@gmail.com> 2013-04-27 11:24:52 PDT --- In here, following mechanism would work for overload resolution. 0. Integer literal 0 and 1 have `int` type, and it does not exactly match to bool and long. 1. bool is regarded as an integer type which has the value 0 or 1. 2. Integer literal 0 and 1 matches to bool with Value Range Propagation (VRP). 3. In general, long values don't match to bool type, but bool values match to long type. So, foo(bool) is more specialized than foo(long) Finally: - foo(0) and foo(1) satisfy all of above conditions, so match to foo(bool). - foo(2) does not satisfy #2, then matches to foo(long). This is a *designed* behavior, but most D users would expect that integer literal value prefers integer overload version. From the user's view, this behavior is *unnatural*. In D, if function arguments match to two or more functions, the ambiguity would be resolved with "partial ordering rule". In above, #3 is corresponding to that. To make the overload resolution mechanism more natural, I think we need to add a special rule there. That is: In partial ordering resolution, bool parameter is treated as less specialized than other integer types (byte, ubyte, short, ushort, int, uint, long, ulong, char, wchar, dchar). The bool literals 'true' and 'false' always don't match to other integer types, so the 'special case' does not affect to other existing overload resolution result IMO. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------