Make pointer::byte_offset_from more generic

[WaffleLapkin]

As suggested by #96283 (comment) (cc @scottmcm), make pointer::byte_offset_from work on pointers of different types. byte_offset_from really doesn't care about pointer types, so this is totally fine and, for example, allows patterns like this:

ptr::addr_of!(x.b).byte_offset_from(ptr::addr_of!(x))

The only possible downside is that this removes the T == U hint to inference, but I don't think this matter much. I don't think there are a lot of cases where you'd want to use byte_offset_from with a pointer of unbounded type (and in such cases you can just specify the type).

@rustbot label +T-libs-api

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Aaron1011]

I'm concerned that this makes the API a little easier to misuse. Both pointers need to be in the same allocation with the same provenance, which seems "less likely" if the types are different. I could imagine someone accidentally passing in the wrong pointer, and having their mistake caught due to a type error.

If it's rare in practice to call this with two differently-typed pointers, than I think it would be better tor require an explicit cast on the caller side.

[scottmcm]

The problem I have here is that if the types are the same, why wouldn't the caller be using offset_from? It's not obvious to me that telling someone to cast their *const i16 to a *const u64 in order to call this is a net win, since potentially-misaligned pointers like that are a slight code odor. (Maybe not even a smell, but still an indication that an extra look is encouraged.) And if it ends up being .byte_offset_from(p.cast()) -- or worse, .byte_offset_from(p as _) -- in most of the calls, that's not necessarily a win. After all, this is just a convenience method to avoid a .cast::<u8>(), so if one needs to cast one of the pointers, maybe just cast both of them.

But I guess it's hard to make a good case either way since there appear to be literally zero uses of byte_offset_from in the rust repo -- not even doctest examples.

So maybe this really needs a code audit to find places that could use this instead of whatever it's currently doing. That accidentally ended up really helpful in #95837, for example, showing that actually nothing wanted offset_from, and thus encouraging a really short name for the returns-usize-instead-of-isize version.

[scottmcm]

@rustbot label +I-libs-api-nominated +S-waiting-on-team

Hi libs-api! I brought this up, so obviously I think it's a good idea, but given objections raised above I'd like to get extra thoughts on it. Would you rather this stay homogeneous, or should it accept mixed types of pointers?

[m-ou-se]

We discussed this very briefly in the libs-api meeting. This change looks fine to us. :)

[scottmcm]

With the ok for nightly from libs-api,
@bors r+ rollup

[bors]

📌 Commit 6279d09 has been approved by scottmcm

It is now in the queue for this repository.