disallow slicing array values

[mlugg]

Background

The slicing operator in Zig, a[b..c], expects a to be either a slice(*) or an array, and returns a slice(*) of the elements between index b and c. That's all well and good... except for one thing. If a can be an array, then this syntax form needs to take its address (i.e. &a) in order to return a slice! Of course, that's not necessary if a is a slice, but we need to decide how we're evaluating a before we learn its type, so we need to assume the worst and always take the implicit reference, then dereference that pointer again if it turned out to already be a slice (which is the far more common case!).

Taking addresses unnecessarily is generally undesirable. The main reason for this is that it harms our heuristic for "local variable is never mutated" compile errors -- for instance, the following snippet does not emit a compile error:

test {
    // incorrect use of 'var': we don't mutate the *slice*!
    var buf = try std.testing.allocator.alloc(u8, 10);
    defer std.testing.allocator.free(buf);
    // the compiler sees `buf[5..]`, and realises that if `buf` is an array, this code
    // actually will mutate it. therefore, it cannot emit the compile error, even though
    // in reality, `buf` is a slice, not an array.
    const part = buf[5..];
    part[0] = 123;
}
const std = @import("std");

(*): or pointer-to-array, which by design acts almost identically to a slice

Proposal

Remove the ability to use slicing syntax (a[b..], a[b..c], a[b.. :d], a[b..c :d]) to get a slice from an array.

The breakages of user code are summarized by this theoretical diff:

 test {
     var arr: [10]u8 = undefined;
     // using slicing to actually get a sub-slice of the array
-    @memcpy(arr[0..5], "hello");
+    @memcpy((&arr)[0..5], "hello");
     // using slicing just to turn an array into a slice
-    otherStuff(arr[0..]);
+    otherStuff(&arr);
     // unnecessary use of 'var'
-    var ptr = &arr;
+    const ptr = &arr;
     @memset(ptr[5..], 0);
 }

(To be clear, that third example is just a slight variant of the "unnecessary use of var" snippet I showed earlier; that earlier example would also need changing.)

The first change above is perhaps mildly annoying, but I would argue improves clarity, particularly in situations where double-pointers might be involved. The second is an improvement because it gives one obvious way to do array->slice conversion (whereas today, some people do still write arr[0..] for that). The third is an obvious improvement.

All three of the previously-working lines in the above snippet will fail with compile errors. In order:

error: cannot slice array value
note: use '&' to convert array to slice

error: cannot slice array value
note: use '&' to convert array to slice

error: local variable is never mutated
note: consider using 'const'

[rohlem]

I like how this would make & the only operator for referencing / taking an address of something, removing the potential footgun of implicit reference from slicing.
(For completeness, the complement idea of making slicing operate only as value -> value was already discussed previously in #14359 / #21960 .)

[IntegratedQuantum]

This reminds me a lot of the workaround for array access performance problems #13938
Extending this proposal to array accesses could fix these classes of errors, although it would be quite annoying.

[mlugg]

We have a concrete plan to fix #13938, it just involves some (user-invisible) frontend changes which we haven't gotten around to yet. Array indexing syntax will continue to support direct usage on array values.

[dweiller]

Would it be reasonable to make the reference operator bind tighter than the slicing operator so that first example could be

-    @memcpy(arr[0..5], "hello");
+    @memcpy(&arr[0..5], "hello");

or would that make some precedence rules overly complex/confusing (I'm mostly thinking of comparing with indexing)? I think it would work to simply split up the precedence levels of slicing and indexing and drop slicing to it's own level below that of & in the precedence table while maintaining indexing at the top.

[BraynStorm]

The proposed syntax would make it a bit more difficult to tell if the thing being sliced is an array or a value-on-the-stack.

Array:

const bytes = 1;
var example: [8]u8 = undefined;
foo((&example)[0..bytes]);

Value:

const bytes = 1;
var example: u8 = 42;
foo((&example)[0..bytes]);

Also, the usage of arrays becomes more cumbersome for one of their most-common use cases.

[mlugg]

Would it be reasonable to make the reference operator bind tighter than the slicing operator so that first example could be [...]

It would be very confusing if &arr[0..5] meant (&arr)[0..5], but &arr[2] meant &(arr[2]). It's also just conventional (from e.g. C) that & binds quite loosely; we should follow the principle of least surprise here. The verbosity when writing code really isn't that bad (particularly since slicing arrays isn't crazy common) and I think certainly improves clarity when reading, making the parentheses an overall win compared to changing precedence.

The proposed syntax would make it a bit more difficult to tell if the thing being sliced is an array or a value-on-the-stack.

I actually think the change here is a positive one. Status quo is a bit odd, because lhs[0..1] will (successfully) take a pointer to lhs for you if and only if it happens to be an array (as opposed to a non-array value for which we want to make a *[1]T). In other words, your two snippets are doing the same kind of thing: both are constructing pointers to stack memory, it's just that the first one reserves a bit more stack memory. To me, it's really quite odd that in status quo, these two operations, which are essentially identical, have a syntactic difference.

It's certainly true that you need to know the types of the things you're slicing to understand the behavior, but that's already the case with this syntax. (I still personally believe that single_ptr[0..1] isn't a great syntax for *T -> *[1]T conversion because of this property; hopefully at some point I think of a better syntax to propose at some point, but that's not relevant here.)

Also, the usage of arrays becomes more cumbersome for one of their most-common use cases.

I wouldn't consider it particularly more cumbersome. Slicing is also not a crazy common operation in my experience. If you have an example of a real code snippet which you think this proposal would make worse (especially if you think it becomes less readable), I would be happy to take a look at it.

[BraynStorm]

[snip] we should follow the principle of least surprise here [snip]

I totally agree, especially about the &arr[x] change which would be quite confusing, but also in general.

Slicing is also not a crazy common operation in my experience.

Point taken, I had a hard time finding usages of arr[x..y] in my code - it is used, but not very common, and I had assumed it was more common.

---

At the end of the day I would assume most people expect slices and arrays to have more-or-less the same syntax - both can be xyz[i]'d and both can be xyz[i..j]'d. They are a "pair-of-pointers", difference is the array's length is known at compile time.

With the proposed changes, you'd leave only the first one being an option for arrays, but not the second one. Feels very strange to me, but I write mostly Python and C++ on my day-job, so I'm very biased.

With struct values vs struct pointers you get the same syntax for accessing fields, unlike C. Maybe we should keep the same syntax matching with array values and array pointers like C?

I assume you can still get the old syntax with something like this:

var buffer: [256]u8 = undefined;
const buf = &buffer;  // type = *[256]u8
// ...
foo(buf[5..10]);

My takeaway for now is this:

1. Improves "Where do I take a pointer to this stack-variable?" clarity.
2. Improves var/const checks (as far as I understand).
3. Removes "Arrays are just (compile-time-known) slices".
   3.1. Usage is not very common
   3.3. Can recover old syntax trivially (excluding the fact that you need a new name, which is always a pain).
   3.2. Uncertain of optimizer's opinion on this code but probably OK - it's not a slice, but a pointer-to-array so the pointless bounds check should always disappear.

---

My opinion is not that strong either way.

[mlugg]

At the end of the day I would assume most people expect slices and arrays to have more-or-less the same syntax - both can be xyz[i]'d and both can be xyz[i..j]'d.

I totally understand why you would make this assumption, but the reason it doesn't work is that the latter returns a slice, i.e. a pointer, and you cannot get a pointer given just an array value; whereas for the former, getting a pointer (/slice) is fine, because you can get a value out of a pointer (you just load from the pointer). Put simply, you can convert from pointer to value, but you can't convert from value to pointer (hence why slicing syntax currently has to do this by evaluating its LHS in a different way). I too have felt tempted in the past to make these operations mirror one another better, but have since come to the realisation that they are quite fundamentally different for this simple reason.

I assume you can still get the old syntax with something like this:

Yes, that'll work fine.

[bangbangsheshotmedown]

Another case of: let's make the language worse because of OP's skill issue

Slicing is also not a crazy common operation in my experience.

I suggest you think about what you just said...

[mlugg]

Another case of: let's make the language worse because of OP's skill issue

Please refrain from making personal attacks. I also don't know what "OP's skill issue" is even referring to here. If you wish to contribute, please explain how this makes the language worse, ideally with an example of code which would be negatively affected.

I suggest you think about what you just said...

I have. Slicing -- especially slicing array values -- is a relatively infrequent operation. If you have actual counterexamples, please provide them.

[andrewrk]

I think this is worth seriously considering and the next step is to examine a diff that changes a major codebase into adhering to this new rule and see what the breakage looks like.