Proposal: overload conflict resolution
Chris Miller
chris at dprogramming.com
Sun Dec 10 10:20:54 PST 2006
On Sun, 10 Dec 2006 11:58:35 -0500, Frits van Bommel
<fvbommel at REMwOVExCAPSs.nl> wrote:
> Chris Miller wrote:
>> Given the following function prototypes:
>> void foo(char[] s);
>> void foo(wchar[] s);
>> void foo(dchar[] s);
>> Currently, if you try to do foo("hello"), the compiler will complain
>> because string literals simulteneous match all the above types.
>> Proposal:
>> void foo(default char[] s);
>> void foo(wchar[] s);
>> void foo(dchar[] s);
> <snip>
>> The compiler would go down the line of parameters of overloads, and
>> upon any conflicts, would look for default to resolve them. If default
>> is used to resolve conflicts in more that one of the functions, it's an
>> actual conflict.
>> Strange example:
>> void bar(default char[] s, int x);
>> void bar(char[] s, default long x);
>
> I like the basic idea, but maybe it gets a bit to hairy when multiple
> parameters can have this attribute...
>
> Maybe it should be an attribute of the function instead?
> Then it becomes quite clear, I think: if there are multiple equally-good
> matches and among them the number of overloads with the attribute is
> anything other than one (that is, none or at least two) it's still an
> error, otherwise the one declared 'default' is picked.
I thought of it and generally agree it reduces complexity, but doesn't
give as much control. Consider one name that has overloads with many
different types, like toString; it has conflicts with numbers, strings,
and whatever else. Also consider when more than one parameter is involved.
I'm not sure which is the better tradeoff.
More information about the Digitalmars-d
mailing list