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