On Sun, 14 Aug 2005 18:07:45 +0000 (UTC), Manfred Nowak wrote:

> Derek Parnell <derek@psych.ward> wrote:
> 
> [...]
>> the encoding of the
>> source text should be independent of the interpretation of
>> undecorated string literals. Just because a file is encoded as
>> UTF8 there should be no restriction on me deciding to save the
>> file as UTF16. The compiler should not go choosing which
>> function to call based on how the file just happens to be
>> encoded.
> 
> Nice example, but is this argument suited in general?

Yes.

> How will your embedded string literals be saved to the UTF16-source by your editor?

As UTF16 encoded strings, just like the rest of the text. The editor doesn't distinguish between string literals and other text.

>And once you have changed some of them to real utf16-codes,
> how will your editor save them, if you decide to revert to utf8?

"real utf16-codes"? What are these? If the text is encoded in UTF16 then
the entire text already contains real UTF16 codes. If I decide to save it
as UTF8, then the editor will translate it for me. The way that the text is
displayed remains the same, regardless of its encoding. The storage of the
text is independent of the way it is displayed and interpreted by the
compiler.

>> This sounds more like we need to have a pragma that specifies which default encoding we mean to have on the undecorated literals in a specific source text.
> 
> Agreed. That might be a solution.
> 
> [...]
>>> what will now happen with the call:
>>> 
>>>   func( "\u00001111"d "qwerty"c);
>>> 
>>> Is this ambiguous?
>> 
>> Not to the compiler. If you try this you get the error message
>> 
>>   " mismatched string literal postfixes 'd' and 'c' "
> 
> Yes. But have you tried any further?
> 
> func( "" ""c); //mismatched string literal postfixes ' ' and 'c'
> func( "" ""d); //mismatched string literal postfixes ' ' and 'd'
> 
> Then: an unsuffixed string literal is neither compatibel with c nor d. So what is it, that the compiler complains about undecorated string literals match both char[] and dchar[]?

That has got to be a bug.

> Are we chasing a phantom, because the overloading routine of dmd is broken?

Its not broken. It works as documented.  ;-)



-- 
Derek Parnell
Melbourne, Australia
15/08/2005 8:02:38 AM

"Derek Parnell" <derek@psych.ward> wrote in message news:1fki98rnsnkwe$.11rh18dazasty.dlg@40tude.net...
> On Sun, 14 Aug 2005 18:07:45 +0000 (UTC), Manfred Nowak wrote:
>
>> Derek Parnell <derek@psych.ward> wrote:
>>
>> [...]
>>> the encoding of the
>>> source text should be independent of the interpretation of
>>> undecorated string literals. Just because a file is encoded as
>>> UTF8 there should be no restriction on me deciding to save the
>>> file as UTF16. The compiler should not go choosing which
>>> function to call based on how the file just happens to be
>>> encoded.
>>
>> Nice example, but is this argument suited in general?
>
> Yes.
>
>> How will your
>> embedded string literals be saved to the UTF16-source by your
>> editor?
>
> As UTF16 encoded strings, just like the rest of the text. The editor doesn't distinguish between string literals and other text.
>
>>And once you have changed some of them to real utf16-codes,
>> how will your editor save them, if you decide to revert to utf8?
>
> "real utf16-codes"? What are these? If the text is encoded in UTF16 then
> the entire text already contains real UTF16 codes. If I decide to save it
> as UTF8, then the editor will translate it for me. The way that the text
> is
> displayed remains the same, regardless of its encoding. The storage of the
> text is independent of the way it is displayed and interpreted by the
> compiler.

Agreed. The c/w/d postfix indicates how to store the string in the obj file not how it is stored in the source file.

>>> This sounds more like we need to have a pragma that specifies which default encoding we mean to have on the undecorated literals in a specific source text.
>>
>> Agreed. That might be a solution.
>>
>> [...]
>>>> what will now happen with the call:
>>>>
>>>>   func( "\u00001111"d "qwerty"c);
>>>>
>>>> Is this ambiguous?
>>>
>>> Not to the compiler. If you try this you get the error message
>>>
>>>   " mismatched string literal postfixes 'd' and 'c' "
>>
>> Yes. But have you tried any further?
>>
>> func( "" ""c); //mismatched string literal postfixes ' ' and 'c'
>> func( "" ""d); //mismatched string literal postfixes ' ' and 'd'
>>
>> Then: an unsuffixed string literal is neither compatibel with c nor d. So what is it, that the compiler complains about undecorated string literals match both char[] and dchar[]?
>
> That has got to be a bug.

The current behavior is reasonable to me. It prevents any confusion with
 func(""c "")
should it keep the c postfix or substitute the "empty postfix"? The current
behavior errors and makes the user choose.