[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sat Apr 27 11:24:53 PDT 2013


http://d.puremagic.com/issues/show_bug.cgi?id=9999



--- Comment #1 from Kenji Hara <k.hara.pg at 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: -------


More information about the Digitalmars-d-bugs mailing list