Should this work?

[Regan Heath]

On Fri, 17 Jan 2014 23:58:04 -0000, Marco Leise <Marco.Leise at gmx.de> wrote:

> Am Fri, 17 Jan 2014 21:38:18 +0100
> schrieb Marco Leise <Marco.Leise at gmx.de>:
>
>> 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.
>
> 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/