Ivan Senji wrote:
> Derek Parnell wrote:
> 
>> On Fri, 18 Nov 2005 12:54:38 +0100, Ivan Senji wrote:
>>
>>
>>> Bruno Medeiros wrote:
>>>
>>>> In the following code:
>>>>
>>>>  auto str = cast(wchar[])("123456"c);
>>>>  writefln(typeid(typeof(str)));
>>>>  writefln("str: ", (cast(char[])str).length,": ", (cast(char[])str));
>>>>
>>>> the (original) string literal will be of type wchar[$] and not char[$], as the cast takes precedence over the string decorator.
>>>>
>>>>
>>>
>>> How is that a bug? The type of the right side is wchar[].
>>>
>>> auto x = cast(float)4;
>>>
>>> x is float, not int, same thing above.
>>
>>
>>
>> Almost the same thing but not quite.
>>
> <snip>
> 
> I didn't try/want to start another discussion about string literals. All i was trying to do is  to explain to Bruno why str from his post has the type it has (because of cast).
> 
...
> 
> My point was that the type of any expression is that of a type it is being cast to if that cast is legal.
I know why my str var will be of type wchar[], and that is totally irrelevant. str would allways be of type wchar[], even if this bug/idiom was fixed.
The problem is the char[] *literal*, which will be transcoded to wchar[], which in turn would not happen if the char[] was not a literal (and it is here that we perceive an inconsistency). That is, the following code will not produce the same results:

	auto cstr = "123456"c;
	auto str = cast(wchar[])(cstr);
	...

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Bruno Medeiros wrote:
> Ivan Senji wrote:
> 
>> Derek Parnell wrote:
>>
>>> On Fri, 18 Nov 2005 12:54:38 +0100, Ivan Senji wrote:
>>>
>>>
>>>> Bruno Medeiros wrote:
>>>>
>>>>> In the following code:
>>>>>
>>>>>  auto str = cast(wchar[])("123456"c);
>>>>>  writefln(typeid(typeof(str)));
>>>>>  writefln("str: ", (cast(char[])str).length,": ", (cast(char[])str));
>>>>>
>>>>> the (original) string literal will be of type wchar[$] and not char[$], as the cast takes precedence over the string decorator.
>>>>>
>>>>>
>>>>
>>>> How is that a bug? The type of the right side is wchar[].
>>>>
>>>> auto x = cast(float)4;
>>>>
>>>> x is float, not int, same thing above.
>>>
>>>
>>>
>>>
>>> Almost the same thing but not quite.
>>>
>> <snip>
>>
>> I didn't try/want to start another discussion about string literals. All i was trying to do is  to explain to Bruno why str from his post has the type it has (because of cast).
>>
> ....
> 
>>
>> My point was that the type of any expression is that of a type it is being cast to if that cast is legal.
> 
> I know why my str var will be of type wchar[], and that is totally irrelevant. str would allways be of type wchar[], even if this bug/idiom was fixed.
> The problem is the char[] *literal*, which will be transcoded to wchar[], which in turn would not happen if the char[] was not a literal (and it is here that we perceive an inconsistency). That is, the following code will not produce the same results:

I think i see the problem (and the solution) now: cast shouldn't transcode string literals.

> 
>     auto cstr = "123456"c;
>     auto str = cast(wchar[])(cstr);
>     ...
>