On 03/18/2017 01:22 PM, Oleg B wrote:
enum arr = cast(ubyte[])[0,0,0,1,0,0,0,2,0,0,0,3,0,0,0,4];
auto arr1 = cast(void[])arr;
immutable arr2 = cast(immutable(void)[])arr;
enum arr3 = cast(void[])arr;
Aside: The casts here do nothing to affect the outcome.
writeln(cast(ushort[])arr1); // [0, 256, 0, 512, 0, 768, 0, 1024]
writeln(cast(ushort[])arr2); // [0, 256, 0, 512, 0, 768, 0, 1024]
writeln(cast(ushort[])arr3); // [0, 0, 0, 1, 0, 0, 0, 2, 0, 0, 0, 3,
0, 0, 0, 4]
I guess the last one here is supposed to be the surprising one. I find
them all surprising, actually.
`arr` itself is already not what I'd expect. It should be an array with
64 elements, because you're casting an array of 16 int elements to
ubyte[] (16 * int.sizeof = 64).
At least that's how it works with a run-time array:
auto a = [0,0,0,1,0,0,0,2,0,0,0,3,0,0,0,4];
auto b = cast(ubyte[]) a;
assert(b.length == 64);
But when the source is a literal or an enum, the cast doesn't change the
length. Instead the elements are casted individually. I'd call this a
bug. It's definitely surprising.
It's also potentially throwing data away:
writeln(cast(ubyte[]) [257, 2, 3, 4]); /* [1, 2, 3, 4] */
Run-time array casts don't do that.
