Comment #0 by bearophile_hugs — 2012-02-15T18:32:14Z
D2 code:
void main() {
char[] s = "ABC".dup;
auto a = cast(char[3])s;
}
I think the error message contains "e2ir: " by mistake, DMD 2.058:
test.d(3): Error: e2ir: cannot cast s of type char[] to type char[3u]
Comment #1 by yebblies — 2012-02-15T19:50:08Z
*** This issue has been marked as a duplicate of issue 5113 ***
Comment #2 by verylonglogin.reg — 2013-11-09T10:30:28Z
(In reply to comment #0)
> I think the error message contains "e2ir: " by mistake, DMD 2.058:
It's a minor dmd ICE.
Comment #3 by yebblies — 2013-11-16T20:37:34Z
I put the fix in the pull in issue 11484
Comment #4 by yebblies — 2013-11-16T20:38:07Z
*** Issue 5113 has been marked as a duplicate of this issue. ***
Comment #5 by yebblies — 2014-01-24T22:43:00Z
Tricky, thanks to this:
auto str2 = cast(wchar[3])("789abc"c);
writefln("str2: ", (cast(char[])str2).length , " : ", (cast(char[])str2));
assert(cast(char[])str2 == "789abc"c);
I think we should disallow casting a string literal to a static array with a different character size.
Comment #6 by bearophile_hugs — 2015-01-15T02:09:19Z
Another case (according to Kenji Hara):
void main() /*@nogc*/ {
int[2][1] m = cast(int[2][1])[1, 2];
}
Gives:
test2.d(2,34): Error: e2ir: cannot cast [1, 2] of type int[] to type int[2][1]
Comment #7 by k.hara.pg — 2015-01-15T02:10:56Z
*** Issue 13849 has been marked as a duplicate of this issue. ***
Comment #8 by bearophile_hugs — 2015-01-15T02:12:59Z
(In reply to Kenji Hara from comment #7)
> *** Issue 13849 has been marked as a duplicate of this issue. ***
Your have asked me to aggregate two different problems:
- This issue originally was just asking to remove the "e2ir" in the error message. This is a bug report.
- Now this issue is also an enhancement request, asking for code like "int[2][1] m = cast(int[2][1])[1, 2];" to be accepted.
Comment #9 by bearophile_hugs — 2015-01-15T02:15:48Z
(In reply to bearophile_hugs from comment #8)
> Your have asked me to aggregate two different problems:
And now you have also aggregated:
void main() @safe {
immutable ulong x = 10;
auto y1 = cast(uint[2])x; // Error
auto y2 = cast(uint[2])[x]; // Error
immutable ulong[] x2 = [10];
auto y3 = cast(uint[2])x2; // Error
immutable ulong[1] x3 = [10];
auto y4 = cast(uint[2])x3; // OK
}
Comment #10 by k.hara.pg — 2015-01-15T04:09:19Z
(In reply to bearophile_hugs from comment #8)
> Your have asked me to aggregate two different problems:
> - This issue originally was just asking to remove the "e2ir" in the error
> message. This is a bug report.
It's now properly handled in the issue 13810. So I set the "Blocks" field.
> - Now this issue is also an enhancement request, asking for code like
> "int[2][1] m = cast(int[2][1])[1, 2];" to be accepted.
Why? The "Importance" field had not been set to "enhancement" any time. And you had not *ask* the acceptability about the code by the comments.
And, I think the cast from int[] to int[2][1] should not be accepted.
Comment #11 by bearophile_hugs — 2015-01-15T09:20:17Z
(In reply to Kenji Hara from comment #10)
> I think the cast from int[] to int[2][1] should not be accepted.
Can you please explain why?
Currently this is accepted:
int[2] m = cast(int[2])[1, 2];
Comment #12 by k.hara.pg — 2015-01-22T16:22:49Z
(In reply to bearophile_hugs from comment #11)
> (In reply to Kenji Hara from comment #10)
>
> > I think the cast from int[] to int[2][1] should not be accepted.
>
> Can you please explain why?
>
> Currently this is accepted:
> int[2] m = cast(int[2])[1, 2];
In cast(int[2])[1, 2], the array literal can *structurally* match to the type int[2] - all elements can be implicitly convertible to int, and the array literal contains 2 elements. Therefore the cast is accepted.
Contrary to that, in cast(int[2][1])[1, 2] compiler cannot find any structural conversions. Therefore it will be a reinterpret cast, but dmd has no proper codegen way for the cast from int[] to int[2][1].
That's why the former is accepted but the latter isn't.