[REG2.067a] Issue 13775 - Broken explicit casting of dynamic array slices of known size to static array of different type

[9rnsr]

https://issues.dlang.org/show_bug.cgi?id=13775

Support reinterpret-cast from a CT-known boundaries slice expression that can be implicitly typed as T[n] to another static array type U[m], iff their sizes are same (T[n].sizeof == U[m].sizeof).

[Hackerpilot]

I don't see any problems with this.

[yebblies]

Auto-merge toggled on

[CyberShadow]

This code broke the following (used in ae, breaking Digger):

immutable(ubyte)[] data = new ubyte[20].idup;
auto a = cast(ubyte[20])data[0..$];

Was this breakage intentional?

[Geod24]

Thanks for tracing this @CyberShadow :)

Also affects Vibe.d:

            case AF_INET6:
                ubyte[16] ip = addr_ip6.sin6_addr.s6_addr;
                auto ret = appender!string();
                ret.reserve(40);
                foreach (i; 0 .. 8) {
                    if (i > 0) ret.put(':');
                    ret.formattedWrite("%x", bigEndianToNative!ushort(cast(ubyte[2])ip[i*2 .. i*2+2]));
                }

[9rnsr]

Was this breakage intentional?

This PR intentionally rejects the case, because there was a wrong-code bug. See the example code:

void main() {
    immutable(ubyte)[] data = new ubyte[2].idup;
    auto a = cast(ubyte[4])data[0..$];
    // Although $ == 2, the cast will access out of the range of valid memory.

    import std.stdio;
    writeln(a);
    // will print [0, 0, garbage, garbage]
}

And, until 2.062, the reinterpret cast from T[] to T[n] had been constantly disallowed. So the restriction is merely enabled again.

[CyberShadow]

IMHO this should be a runtime check, like with slice copies. So it should throw Array lengths don't match for copy: 4 != 2

[9rnsr]

Of course it's possible, but at least it should be a new enhancement. And the cast would not work under the @nogc semantics so the thrown Error would need allocation.

[CyberShadow]

And the cast would not work under the @nogc semantics so the thrown Error would need allocation.

I thought asserts were exempt from @nogc? At least, you can put assert(false) in a @nogc function.

[9rnsr]

I don't know. At least today range violation handling is not same with assert(false) even in @nogc function.

[CyberShadow]

Another regression filed against this change:

https://issues.dlang.org/show_bug.cgi?id=14582