support pointer arithmetic on pointer to array

[andrewrk]

Similar to #863 (when slicing with a comptime length, result type should be pointer to array), pointers to arrays should support pointer arithmetic. The result type is a pointer to an array with a smaller len, and appropriate alignment. Compile error happens if you go out of bounds.

Ran into this working on https://github.com/andrewrk/zig-general-purpose-allocator/. I correctly used a *align(page_size) [page_size]u8 type, but then had to go back and use the worse option [*]align(page_size) u8 due to not having pointer arithmetic.

In general, users should prefer pointers to arrays when the length is compile time known, and the language should support that preference.

[Hejsil]

Isn't this the same as #863? With that, you could do:

const arr: [50]u8 = undefined;
const arr_ptr = &arr;
_ = @typeOf(arr_ptr[4..]); // *[46]u8
_ = @typeOf(arr_ptr[10..20]); // *[10]u8

[andrewrk]

Good point, I hadn't considered that. Do you think we should not support pointer arithmetic then?

[Hejsil]

@andrewrk Only + could realistically be supported as - would be unsafe. So why have 2 ways of doing the same thing? :)

[andrewrk]

So why have 2 ways of doing the same thing?

Actually I have an answer to that. In generic code you would expect to use + on both an unknown length pointer and a pointer to an array. It's generally supposed to be better to have a pointer to an array than an unknown length pointer wherever possible. So the argument is that if it works for unknown length pointer, and it could work safely for a pointer to array, then it should work.