Proposal: clean up semantics of array literals vs string literals

[Don Clugston]

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.