Am Mon, 13 Jan 2014 11:40:19 -0000 schrieb "Regan Heath" <re...@netmail.co.nz>:
> On Fri, 10 Jan 2014 19:47:07 -0000, H. S. Teoh <hst...@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