Proposal: overload conflict resolution

[Pragma]

Chris Nicholson-Sauls 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);
>>
>> foo("hello")  will now select the char[] version because it was marked 
>> as the default type in the overload.
>>
>> What it does not do:
>>    1) Resolve conflicts between different scopes.
>>    2) Override exact matches.
>>
>> The way overloads work now is helpful in some cases, but in other 
>> cases, it's perfectly fine to prefer an overload over another.
>>
>>
>> Example where you do not want a default overload: working with binary, 
>> e.g. writing to Stream or Socket, where the wrong type can screw up 
>> the format or transmission.
>>
>> Example where you do: custom string object's constructor that wants to 
>> allow char[], wchar[] and dchar[] types, but wants to default string 
>> literals to char[].
>>
>>
>> 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);
>>
>> Note: this example probably wouldn't actually be used; as with most 
>> language constructs, there's a way to abuse it, but this example gets 
>> a point across that it at least has logic:
>> bar("hello", 42)  chooses the first one because the string literal 
>> conflicted and went with the default one.
>> bar("hello"c, 42)  chooses the second one; the string literal 
>> specified char[] (with the c) and then had a conflict with the second 
>> parameter, where default resolved it.
>>
>>
>> The programmer knows which overloads, if any, can be preferred over 
>> others, because this feature works only confined within one scope, and 
>> so it is safe to let him choose for you.
>>
>>
>> Where this can be useful:
>>    1) String literals conflicting with char[], wchar[] and dchar[].
>>    2) null conflicting with string types, delegates, pointers, and 
>> class references.
>>    3) Integer literals conflicting with the number types.
>>    4) Different levels of derived classes conflicting with each other.
>>
>>
>> Thanks,
>> - Chris
> 
> Personally I just don't think I'd ever have a use for it...  Rare is the 
> string literal in my code without a c|w|d suffix.  (Partially because I 
> use Mango an awful lot, which does have a few cases of this ambiguity -- 
> Stdout anyone?  But no problem... I never code Stdout("Hello!") but 
> always Stdout("Hello!"c) instead... tada, problem solved with existing 
> features.
> 
> But apparently a lot of people do see something useful about this.  So I 
> abstain and vote neutral.  :)
> 
> -- Chris Nicholson-Sauls

The Mango example is actually a perfect case for how this can trip 
programmers up.  But you're right, using existing features (as minimally 
intrusive as c/d/w) are the right way to go.

Still, I've often wondered if there wasn't a better way.  Something like 
  auto defining char data as UTF-8/16/32 based on the *source file 
encoding* might go a long way to make this a little more implicit. 
However, I'm not sure if that would be too subtle to maintain practically.

-- 
- EricAnderton at yahoo