Summary: Unclear semantics of array literals of char type, vs
                    string literals
           Product: D
           Version: D1 & D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD

--- Comment #0 from Don <> 2012-09-14 04:28:17 PDT ---
Array literals of char type, have completely different semantics from string
literals. In module scope:

char[] x = ['a'];  // OK -- array literals can have an implicit .dup
char[] y = "b";    // illegal

A second difference is that string literals have a trailing \0. It's important
for compatibility with C, but is barely mentioned in the spec. The spec does
not state if the trailing \0 is still present after operations like

CTFE can use either, but it has to choose one. This leads to odd effects:

string foo(bool b) {
    string c = ['a'];
    string d = "a";
    if (b)
        return c ~ c;
        return c ~ d;

char[] x = foo(true);   // ok
char[] y = foo(false);  // rejected!

This is really bizarre because at run time, there is no difference between
foo(true) and foo(false). They both return a slice of something allocated on
the heap. I think x = foo(true) should be rejected as well, it has an implicit
cast from immutable to mutable.

I think the best way to clean up this mess would be to convert char[] array
literals into string literals whenever possible. This would mean that string
literals may occasionally be of *mutable* type! This would means that whenever
they are assigned to a mutable variable, an implicit .dup gets added (just as
happens now with array literals). The trailing zero would not be duped.
A string literal of mutable type should behaves the way a char[] array literal
behaves now.
A char[] array literal of immutable type should behave the way a string literal
does now.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to