In status quo Zig, you can use ++ with many-ptr operands. The intention (as indicated by comments on the implementation) is that these many-ptrs should be sentinel-terminated, and that the compiler would essentially do std.mem.span for you - in practice, the compiler currently does something much stranger to do with its internal representation of pointers.
Both the actual and intended behavior here seem incorrect. The process of effectively converting a many-ptr to a slice (by virtue of assigning it a length) is not one the compiler should perform implicitly: the user should make this intent clear by performing this conversion in userland, such as with std.mem.span, as is the case for quite literally every other construct in Zig.
I therefore propose that this feature be removed, and that instead the operands to ++ must have a known length (i.e. they must be arrays, vectors, tuples, or slices). The migration path for any userland code relying on this feature (if any exists, that is; I highly doubt it does) will simply be to add calls to std.mem.span where needed.
In status quo Zig, you can use
++with many-ptr operands. The intention (as indicated by comments on the implementation) is that these many-ptrs should be sentinel-terminated, and that the compiler would essentially dostd.mem.spanfor you - in practice, the compiler currently does something much stranger to do with its internal representation of pointers.Both the actual and intended behavior here seem incorrect. The process of effectively converting a many-ptr to a slice (by virtue of assigning it a length) is not one the compiler should perform implicitly: the user should make this intent clear by performing this conversion in userland, such as with
std.mem.span, as is the case for quite literally every other construct in Zig.I therefore propose that this feature be removed, and that instead the operands to
++must have a known length (i.e. they must be arrays, vectors, tuples, or slices). The migration path for any userland code relying on this feature (if any exists, that is; I highly doubt it does) will simply be to add calls tostd.mem.spanwhere needed.