-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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 sub_ptr
(feature ptr_sub_ptr
)
#95892
Comments
I will always prefer this to the use of |
I also wonder if we could just say this doesn't panic but just return the absolute since we assert the greater than equal why not just make it return absolute ? this would cost nothing more and would remove the burden for dev to think about order, and we could just call this |
I would be strongly against this returning the absolute difference between the pointers. Part of the value of this API is that it's more efficient than Adding a separate absolute difference API for pointers might make sense, like the integers have, but it wouldn't be a serviceable replacement for the current (Oh, and as prior art, |
I proposed this cause you write in the PR:
so I expect it to be "free", I'm all in favor of remove all assert since the method is unsafe anyway, this kind of operation should be as fast as possible. I just see this line and wonder, well if it's free why not ?
I don't think C++ std using distance name wrongly is a good point, have you ever see "this object is |
|
Since |
Yeah, if this stabilizes after the other |
I've read some of the bikeshedding in #95837, and I'd like to second @Gankra's suggestion of "offset_to" - it's not perfect, but when I was looking for this method, I couldn't find it in the autocomplete and had to search for the Are there any blockers for stabilization besides the name? I'm not familiar with the stabilization process, but I'd be willing to open a stabilization PR for this if that would help. |
So Once this is stable we can put a note in the |
In isolation, it doesn't make much sense to me either - given the chance to go back in time, I would have made Another possibility may be |
This is an API that naturally should exist as a combination of byte_offset_from and sub_ptr both existing (they showed up at similar times so this union was never made). Adding these is a logical (and perhaps final) precondition of stabilizing ptr_sub_ptr (rust-lang#95892).
feat(byte_sub_ptr): add ptr::byte_sub_ptr This is an API that naturally should exist as a combination of byte_offset_from and sub_ptr both existing (they showed up at similar times so this union was never made). Adding these is a logical (and perhaps final) precondition of stabilizing ptr_sub_ptr (rust-lang#95892).
feat(byte_sub_ptr): add ptr::byte_sub_ptr This is an API that naturally should exist as a combination of byte_offset_from and sub_ptr both existing (they showed up at similar times so this union was never made). Adding these is a logical (and perhaps final) precondition of stabilizing ptr_sub_ptr (rust-lang#95892).
Feature gate:
#![feature(ptr_sub_ptr)]
&#![feature(const_ptr_sub_ptr)]
This is a tracking issue for the
<*const _>::sub_ptr
&<*mut _>::sub_ptr
methods.This is the produces-
usize
version ofoffset_from
, the same way thatadd
andsub
are the takes-usize
versions ofoffset
.It turns out that people almost always actually know which pointer is greater than which when doing this operation, and would rather a
usize
instead of anisize
-- every use ofoffset_from
in the library was followed withas usize
in practice. So like how.add(d)
greatly improved code compared to needing.offset(d as isize)
, being able to useptr.sub_ptr(origin)
instead ofptr.offset_from(origin) as usize
is also a major improvement. And Miri can check the unsafety better, too, since if you get the order wrong it'll detect that, unlike happens with theas usize
approach.This also tracks the
const
ness of operations, though with #92980 stabilizingoffset_from
beingconst
, this beingconst
is likely uncontroversial.Public API
Steps / History
sub_ptr
on pointers (theusize
version ofoffset_from
) #95837Unresolved Questions
add
andsub
methods, but there might be another name that would be more evocative for people Addsub_ptr
on pointers (theusize
version ofoffset_from
) #95837 (comment)The text was updated successfully, but these errors were encountered: