empty slice should still assign ptr properly

[BarabasGitHub]

Zig version: 0.5.0+153c6cf92

const testing = @import("std").testing;
test "empty slice ptr" {
    const a : []u8 = try testing.allocator.alloc(u8, 10);
    defer testing.allocator.free(a);
    var b : []u8 = a[0..0];
    var c : []u8 = undefined;
    c = a[0..0];
    testing.expectEqual(a.ptr, b.ptr); // works
    testing.expectEqual(a.ptr, c.ptr); // fails
}

It's also works fine using an array to initialize the first slice somehow:

const testing = @import("std").testing;
test "empty slice ptr" {
    const a : []u8 = &[_]u8{1,2,3,4};
    var b : []u8 = a[0..0];
    var c : []u8 = undefined;
    c = a[0..0];
    testing.expectEqual(a.ptr, b.ptr);
    testing.expectEqual(a.ptr, c.ptr);
}

My git bisect said: 2182d28cb0917b8d869d13802a5955ee35b4537a is the first bad commit

[BarabasGitHub]

My current workaround is to assign to ptr and len explicitly. (Kinda surprised that's allowed, but ok.)

[andrewrk]

This was a language decision that consciously changed in that commit. But let's make it a bit more formal, by at least having this be a proposal to revert the language semantics.

[BarabasGitHub]

What's the behaviour supposed to be then?
Because currently it only in a very specific case where it doesn't assign the ptr property as I'd expect.

In my use case I have multiple slices. One with the full memory block and another with the part that's actually in use. Sometimes it has to be reset to be empty which is done with [0..0], which is the only time it ends up with an incorrect value. (Actually in the init function where it starts with some capacity.) It's very surprising to me and I don't immediately see how it makes sense. So yes I'd like to propose to revert to the old behaviour of always assigning the pointer when I set a slice, whether it's with a comptime known empty array or not.

[daurnimator]

This bit me when I had an ArrayList with 0 items (but large capacity): the .ptr field of the slice got set to null.