Proposal: clean up semantics of array literals vs string literals

[deadalnix]

Le 02/10/2012 15:12, Don Clugston a écrit :
> On 02/10/12 13:26, deadalnix wrote:
>> Well the whole mess come from the fact that D conflate C string and D
>> string.
>>
>> The first problem come from the fact that D array are implicitly
>> convertible to pointer. So calling D function that expect a char* is
>> possible with D string even if it is unsafe and will not work in the
>> general case.
>>
>> The fact that D provide tricks that will make it work in special cases
>> is armful as previous discussion have shown (many D programmer assume
>> that this will always work because of toy tests they have made, where in
>> case it won't and toStringz must be used).
>>
>> The only sane solution I can think of is to :
>> - disallow slice to convert implicitly to pointer. .ptr is made for that.
>> - Do not put any trailing 0 in string literal, unless it is specified
>> explicitly ( "foobar\0" ).
>> - Except if a const(char)* is expected from the string literal. In
>> case it becomes a Cstring literal, with a trailing 0. This is made to
>> allow uses like printf("foobar");
>>
>> In other terms, the receiver type is used to decide if the compiler
>> generate a string literal or a Cstring literal.
>
> This still doesn't solve the problem of the difference between array
> literals and string literals (the magical implicit .dup), which is the
> key problem I'm trying to solve.
>

OK, infact we have 2 different and unrelated problems here. I have to 
say I have no idea for the second one.