Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: do not allow ++ on many-ptrs #19435

Closed
mlugg opened this issue Mar 26, 2024 · 0 comments
Closed

Proposal: do not allow ++ on many-ptrs #19435

mlugg opened this issue Mar 26, 2024 · 0 comments
Labels
accepted This proposal is planned. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@mlugg
Copy link
Member

mlugg commented Mar 26, 2024

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.

@mlugg mlugg added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label Mar 26, 2024
mlugg added a commit to mlugg/zig that referenced this issue Mar 26, 2024
This commit also performs some refactors to `TypedValue.print` in
preparation for improved comptime pointer access logic. Once that logic
exists, `TypedValue.print` can use Sema to access pointers for more
helpful printing.

This commit also implements proposal ziglang#19435, because the existing logic
there relied on some blatantly incorrect code in `Value.sliceLen`.

Resolves: ziglang#19435
mlugg added a commit to mlugg/zig that referenced this issue Mar 26, 2024
This commit also performs some refactors to `TypedValue.print` in
preparation for improved comptime pointer access logic. Once that logic
exists, `TypedValue.print` can use Sema to access pointers for more
helpful printing.

This commit also implements proposal ziglang#19435, because the existing logic
there relied on some blatantly incorrect code in `Value.sliceLen`.

Resolves: ziglang#19435
@Vexu Vexu modified the milestones: 0.13.0, 0.12.0 Mar 26, 2024
@andrewrk andrewrk modified the milestones: 0.12.0, 0.13.0 Mar 26, 2024
@andrewrk andrewrk added the accepted This proposal is planned. label Mar 26, 2024
@Vexu Vexu modified the milestones: 0.13.0, 0.12.0 Mar 28, 2024
Rexicon226 pushed a commit to Rexicon226/zig that referenced this issue Mar 29, 2024
This commit also performs some refactors to `TypedValue.print` in
preparation for improved comptime pointer access logic. Once that logic
exists, `TypedValue.print` can use Sema to access pointers for more
helpful printing.

This commit also implements proposal ziglang#19435, because the existing logic
there relied on some blatantly incorrect code in `Value.sliceLen`.

Resolves: ziglang#19435
Rexicon226 pushed a commit to Rexicon226/zig that referenced this issue Mar 29, 2024
This commit also performs some refactors to `TypedValue.print` in
preparation for improved comptime pointer access logic. Once that logic
exists, `TypedValue.print` can use Sema to access pointers for more
helpful printing.

This commit also implements proposal ziglang#19435, because the existing logic
there relied on some blatantly incorrect code in `Value.sliceLen`.

Resolves: ziglang#19435
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted This proposal is planned. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

3 participants