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
Tracking issue for vec_into_raw_parts
#65816
Comments
Should the returned pointer be a |
Add {String,Vec}::into_raw_parts Aspects to address: - [x] Create a tracking issue - rust-lang#65816
Add {String,Vec}::into_raw_parts Aspects to address: - [x] Create a tracking issue - rust-lang#65816
Should these functions be associated functions like |
Here's an example where this might have helped with avoiding UB: confio/go-rust-demo#1 (comment). There, the vector was destructed manually and |
Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead, then the code here will need to be adjusted to take it into account (issue rust-lang#65816)
Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Improved layout checks, type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead, then the code here will need to be adjusted to take it into account (issue rust-lang#65816) Reduce the whitespace of safety comments
If we view this as being the opposite of
|
I think it’s not at all obvious that deliberately making this method "weird" is a good thing. |
The method is weird either way. "This uses the vec by |
I don’t see how that makes it weird. |
But into_boxed_slice doesn't leak the memory |
Well,the documentation does a great job telling you how to avoid a leak and also leaking it is not unsafe. |
I don't disagree with any of that, but also my opinion is unchanged. It's not a big deal to have this as associated function vs method, but But again it's a totally unimportant difference either way, and we should just stabilize either form and get on with the day. |
In my opinion functions that start with |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@rust-lang/libs Any thoughts on the unresolved questions in the issue description? I’d be inclined to say:
|
@SimonSapin SGTM. The missing parallelism between definitions of |
I never stated my preference: I do think that it should be an associated function. My rationale is purely based on consistency. I will probably always use this function as Arguing against myself, if the team goes with a method, the associated function syntax will still work, so I'll be able to do what I want. In that case the methods won't be consistent across types, and to me will be a wart.
To be clear, there's no technical reason that prevents the team from choosing to make this an associated function, AFAIK. There's just no technical reason that forces it to be an associated function. |
To clarify, by "missing parallelism," I was referring to the fact that |
|
Why would the returned pointer be marked Edit: Just remembered the stdlib hacks the pointer into being something like 4 so it's technically |
The vec pointer being NonNull gives Vec a niche, so that types like I don't see how it's disingenuous. It really doesn't allocate. |
Ah, that's an interesting implementation detail. I wasn't aware Rust made that kind of optimization so thank you for the correction. What does a user gain if the result of In the case of returning a simple Imo, it's much more apparent to check a raw pointer for being null than it is to check a In the case of
I'm not sure if |
You don’t need to check the pointer for being dangling. The valid region of memory you can access through the pointer has size
size_of::<T>() * old_len == size_of::<U>() * new_len &&
size_of::<T>() * old_capacity == size_of::<U>() * new_capacity &&
align_of::<T>() == align_of::<U>() |
|
That’s a good point. We could limit |
That method, |
Could I ask for clarification on that? The documentation of |
Changing the variable name to match my previous example:
This is not the same as “ |
Hey folks, I don't mean to add noise to an old tracking issue, but I was hoping to add some input on the usability of returning the triple as a tuple. I never remember what order capacity and length are returned in and always have to look at the docs. I have a small utility crate that makes this a bit easier by returning a struct with named fields. Is returning a struct instead of a tuple that has two fields of the same type too wild of a change to consider? I see that this thread already is considering breaking parallelism with |
To put in my own two cents (whatever they're worth), I really don't think that using
Especially since we already have Meanwhile, a For code that really needs For these reasons, my preference is to continue to return |
I think we just need a raw pointer here, does not really need a NonNull wrapper over it since we probably would also make it as a raw pointer. |
#65705 adds:
Things to evaluate before stabilization
NonNull<* mut T>
?The text was updated successfully, but these errors were encountered: