Skip to content

Remove std.mem.toSliceConst, have toSlice return the const-ness of its argument #3985

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.

Sign up for GitHub

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

Jump to bottom
Closed
daurnimator opened this issue Dec 27, 2019 · 2 comments
Closed

Remove std.mem.toSliceConst, have toSlice return the const-ness of its argument #3985

daurnimator opened this issue Dec 27, 2019 · 2 comments
Labels
breaking Implementing this issue could cause existing code to no longer compile or have different behavior. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. standard library This issue involves writing Zig code for the standard library.
Milestone
0.6.0

Comments

@daurnimator
Copy link
Contributor

@daurnimator

It might make sense to remove toSliceConst entirely and have the return value have the const-ness of the argument?

@andrewrk

I agree with this. I would even go so far as to say it's worth having the parameter accept a var type in general to accommodate this.

Originally posted in #3972
@daurnimator daurnimator added proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. standard library This issue involves writing Zig code for the standard library. labels Dec 27, 2019
@daurnimator daurnimator mentioned this issue Dec 27, 2019
Closed
@andrewrk andrewrk added this to the 0.6.0 milestone Dec 31, 2019
@andrewrk andrewrk added the breaking Implementing this issue could cause existing code to no longer compile or have different behavior. label Dec 31, 2019
@andrewrk
Copy link
Member

I opened a related proposal #4000. So far I'm leaning towards accepting both.

@andrewrk
Copy link
Member

andrewrk commented Mar 4, 2020

Done in 5b26128. Deleting deprecated functions will happen naturally, or as part of #1629.

@andrewrk andrewrk closed this as completed Mar 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
breaking Implementing this issue could cause existing code to no longer compile or have different behavior. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. standard library This issue involves writing Zig code for the standard library.
Projects
None yet
Milestone
0.6.0
Development

No branches or pull requests
2 participants
@andrewrk @daurnimator