Should this work?

[Marco Leise]

Am Mon, 13 Jan 2014 11:40:19 -0000
schrieb "Regan Heath" <regan at netmail.co.nz>:

> On Fri, 10 Jan 2014 19:47:07 -0000, H. S. Teoh <hsteoh at quickfur.ath.cx>  
> wrote:
> 
> > On Sat, Jan 11, 2014 at 02:14:41AM +1000, Manu wrote:
> > [...]
> >> One more, again here to reduce spam...
> >>
> >> 2 overloads exist:
> >> void func(const(char)* str);
> >> void func(const(char)[] str);
> >>
> >> Called with literal string:
> >> func("literal");
> >>
> >> called with argument types (string) matches both.
> >>
> >> I appreciate the convenience of the automatic string literal ->
> >> const(char)* cast. But in this case, surely it should just choose the
> >> array version of the function, like it does it calling with a 'string'
> >> variable?  The convenience should be just that, a convenience, not a
> >> hard rule...?
> >
> > File a bug against dmd for this? I agree that it should match the array
> > overload, not the pointer overload. I'm not sure if it's fixable,
> > though, due to the way overloads are resolved currently. But maybe Kenji
> > has a way. ;)
> 
> I think this should remain an error, for the same reason as any other  
> overload resolution error; you might have one, and add the second and  
> silently behaviour changes - this is bad.
> 
> Instead.. isn't the first overload strictly incorrect, unless that first  
> overload expects a null terminated **UTF-8** string.. if it's a C function  
> it should be const(ubyte)* str right?  What overload does D select if you  
> use that instead?
> 
> R

A few days ago I noticed - in shock :D - that I had this
situation with a \0 terminated D string literal and totally
expected the char* overload to be chosen!

I want to object to your claim that C functions should take
const(ubyte)*. When working in Windows that is correct due to
the ANSI/Microsoft codepage madness, but on Mac OS X and Linux
UTF-8 can be assumed.

-- 
Marco