allow chained multi-pointer slicing to omit end value when last one does not

[nektro]

Zig Version

0.11.0-dev.1584+9ccd8ed0a

Steps to Reproduce and Observed Behavior

const std = @import("std");

test {
    const a = [_]u8{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
    const b = &a;
    const c: [*]const u8 = b;
    foo(c[2..][0..3]);
}

fn foo(x: []const u8) !void {
    try std.testing.expectEqualSlices(u8, &.{ 2, 3, 4 }, x);
}

test.zig:7:10: error: slice of pointer must include end value
    foo(c[2..][0..3]);
        ~^~~~~

Expected Behavior

all tests passed

[mlugg]

If you want this why not just do (c + 2)[0..3]? It more accurately describes your intent anyway - c[2..] can't in any meaningful way be a slice, so it's pretty weird for it to be a slicing operation

[ifreund]

This is not a bug, but rather a language proposal.

https://github.com/ziglang/zig/wiki/Language-Proposals

[nektro]

If you want this why not just do (c + 2)[0..3]?

thanks for the insight on this workaround! i do believe that if this was to be implemented it would make the intent more clear and imo "feel" safer, but the latter is generally based on a slight aversion to pointer math so i plenty accept if that ends up being a mark towards a denial

[ifreund]

thanks for the insight on this workaround! i do believe that if this was to be implemented it would make the intent more clear and imo "feel" safer, but thats generally based on a slight aversion to pointer math so i plenty accept if that ends up being a mark towards a denial

The only real difference between slicing and pointer math currently is that slicing is bounds checked. I think adding sugar for writing pointer math as a slicing expression would blur this difference and be inconsistent.

Something "feeling" safer while actually being the exact same thing also seems to be at odds with Zig's preference for explicitness IMO.

[nektro]

The only real difference between slicing and pointer math currently is that slicing is bounds checked.

is this also the case when performed on multi-item pointers, rather than pointers that are already slices?

[nektro]

feels "safer" might not be the right word to describe that I feel like pointer arithmetic (since they only support addition and subtraction) is moreso an artifact of a feature from before slicing syntax existed.

[InKryption]

Would this essentially just boil down to making x[a..] equivalent to x + a?

[rohlem]

I don't think I've seen addition used for slice-offsetting (with proper length reduction) before.
x[a..][..b] looks more heterogenous and "nicer" to me than (x + a)[..b], in part because of the required parentheses.
Now that I know about it, both options make sense in their own regard.

However, there is a difference in behavior, and opportunity for safety checks, with arrays and sentinel-terminated pointers.
Examples (where I took the liberty of allowing x[a..] as its own expression, which goes against the original proposal, but some cases apply either way):

const source: [50:0]u8 = getText();
const ap = source[2..6]; //of type *const [4]u8
const a = ap.*; //of type [4]u8
var b: []u8 = ap;
const intermediate = @as([*:0]u8, source);

const new_syntax_c: [*:0]u8 = intermediate[2..]; //I believe the new syntax should check for the sentinel 0 in source[0..1] be illegal behavior if encountered.
const c: [*:0]u8 = intermediate + 2; //I'm actually not sure whether we do, or should, check for the sentinel with this syntax - imo writer's intent seems not to.

// addition syntax for offsetting:
std.debug.log("{s}", b + 1); //prints source[3..6]
std.debug.log("{s}", ap + 1); //saved by type system: cannot offset pointer-to-single
std.debug.log("{s}", a + 1); //I wouldn't expect this to work (Why would I be talking about a pointer here? Why else would + be array offsetting syntax?)
std.debug.log("{s}", c + 1); //expression allowed, as in initialization of c, again not sure whether it's supposed to check for sentinel though

// new syntax for offsetting:
std.debug.log("{s}", b[1..]); //prints source[3..6] (could be written in status-quo as b[1..b.len])
std.debug.log("{s}", ap[1..]); //prints source[3..6] (could be written in status-quo as a[1..a.len] ... I think .len on arrays still exists?)
std.debug.log("{s}", a[1..]); //same as previous line
std.debug.log("{s}", c[1..]); //checks for sentinel at c[0], then prints source[3..] until sentinel (no succinct way to write this currently - via helper function I guess)