On Fri, 17 Jan 2014 23:58:04 -0000, Marco Leise <[email protected]> wrote:
Am Fri, 17 Jan 2014 21:38:18 +0100
schrieb Marco Leise <[email protected]>:
Am Mon, 13 Jan 2014 11:40:19 -0000
schrieb "Regan Heath" <[email protected]>:
> On Fri, 10 Jan 2014 19:47:07 -0000, H. S. Teoh
<[email protected]>
> 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.
Then again, technically you can still set any encoding you
like, so my argument is moot and you are correct that
const(ubyte)* should be used in any case.
I was thinking in a very Windows centric way when I wrote my comment but
it doesn't surprise me that other platforms can be configured to other
locales. What do they default to?
The last Linux install I did was for my Raspberry Pi and UTF-8 was
recommended, and I selected it, and yet still I had to break out some
weird console magic to fully realise that choice (I think there was a
disjoint component which had not been configured correctly.. some part of
the installation dropped the ball).
Heck, even most of Phobos probably passes UTF-8 directly into
OS APIs without converting to the current locale. :p
Yeah, and it's only "working" because UTF-8 etc is a superset of ASCII, or
they've defaulted or been set to UTF-8 locale, or on windows the Win32 W
function API accepts UTF-16 and we pass that instead.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
