Cast from slices to array pointers

[Hejsil]

Array pointers are slices, but with a length known at compile time. This is powerful because it allows many of Zig's compile time constructs to work on them such as comptime bound check for constants and inline for (inline for can't unroll runtime arrays. We can use inline while to do it though).

I propose making it safer and easier to convert from slices to array pointers so that it encourages people to utilize the static guarantees that array pointers provide.

const s : []const u8 = "ABCD";

// Currently, we can do:
comptime assert(@typeOf(@ptrCast(&const [1]u8, s[1..2].ptr)) == &const [1]u8);

// Option 1: Slicing with constant values should return an array pointer
comptime assert(@typeOf(s[1..2]) == &const [1]u8);

// Option 2: Explicit cast from slice to array pointer. The cast will assert that the slices length is >= the array
comptime assert(@typeOf((&const [1]u8)(s[1..])) == &const [1]u8);

The current method is no good. ptrCast is a scary builtin, and leaving out the 2 in s[1..2] will bypass the safety check that ensures that our slice is at least the size of the array we are casting too.

Option 1 has some upsides. It will seamlessly flow around array pointers, giving you all their benefits without you even trying. Plus, array pointers should implicitly cast to slices (currently, only &const [1]u8 -> []const u8 works, not &[1]u8 -> []u8), so this shouldn't break much code. This does have the downside that changing a const declaration to var might break code that relies on these implicit array pointers.

Option 2 favors the programmer being more explicit about when they want the static guaranty of the array pointer. This allows a more clearly expressed intent, and code your code will only break in predictable ways when consts are changed to var (where the cast takes place).

Note, that indexing array pointers right now is a pain, as [] works on both pointers and arrays. #770 Fixes this.

[andrewrk]

I like Option 1. Let's implement that and then see if we need to introduce anything else to make slicing seamless.

[andrewrk]

Note after implementing this, audit all the calls to readIntSlice* and writeIntSlice* and make them call the array variants instead.

[Hejsil]

Here is a fun thing this proposals will allow

a[1..4].* = b[2..5].*;

[thejoshwolfe]

not sure if this was said already, but you can get a comptime len slice at a runtime offset with a[index..][0..4].

[daurnimator]

Here is a fun thing this proposals will allow

a[1..4].* = b[2..5].*;

Would a[1..4].* = undefined also work to set a subset of an array to undefined at once? This would be good for removing some awkward @memsets around the place.

[emekoi]

would this break zig's "no hidden control flow" or do memsets not count as hidden control flow?

[thejoshwolfe]

"no hidden control flow"

There are a few functions implemented by the compiler that don't count as hidden control flow. memcpy and 128bit arithmetic are some that come to mind. The reason these don't count is that they're defined by the language, not user configurable. It's also not clear in each case if the optimizer will emit a function call or inline the assembly. The fact that there's a jump at all is kind of an implementation detail, not significant to the semantics.

[andrewrk]

Landed in dc04e97.