Bug 7664 – Problem with fixed-sized associative array key assignment

I think this code has to be valid: void main() { auto s = "hello"; uint[immutable char[4]] aa; aa[s[0 .. 4]] = 0; } But DMD 2.059head gives: test.d(4): Error: cannot implicitly convert expression (s[0u..4u]) of type string to immutable(char[4u])

Compiler can calculate the length for s[0 .. 4] in compile time, because both lower bound and upper bound are constant expressions. So converting it to static array type is possible. But, currently, the slice of an array expression is *always* typed as dynamic array type. Therefore it is a constant-folding enhancement, not a bug. Bug 7665 will also settle down to the same mechanism.

(In reply to comment #1) > Compiler can calculate the length for s[0 .. 4] in compile time, because both > lower bound and upper bound are constant expressions. So converting it to > static array type is possible. > > But, currently, the slice of an array expression is *always* typed as dynamic > array type. > Therefore it is a constant-folding enhancement, not a bug. Thank you for your answers. I convert this to enhancement request then. I think such constant-folding is useful to remove some run-time tests and speed up other code that uses slices.

(In reply to comment #2) > Thank you for your answers. I convert this to enhancement request then. > > I think such constant-folding is useful to remove some run-time tests and speed > up other code that uses slices. In really special case, D allows such conversion from dynamic array type to static array type. See following: void foo(immutable(char)[4] s){} void main() { static assert(is(typeof("test") == immutable(char)[])); foo("test"); // immutable(char)[] to immutable(char)[4] foo(['t','e','s','t']); // immutable(char)[] to immutable(char)[4] } So there seems to be enough reasoning for this enhancement.