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

Simplify unaligned Ref constructors #329

Merged
merged 1 commit into from
Sep 6, 2023

Conversation

joshlf
Copy link
Member

@joshlf joshlf commented Sep 5, 2023

These constructors don't currently make use of the T: Unaligned bound internally - they just use it to document that an alignment check is guaranteed to be elided. The alignment check in the non-Unaligned constructors is trivially optimizable when it's unneeded since it's just a check that x % 1 == 0. For that reason, in this commit, we remove these methods' internals and simply have them be wrappers around the equivalent non-Unaligned constructors.

@joshlf joshlf requested a review from jswrenn September 5, 2023 05:12
@joshlf joshlf force-pushed the known-layout-1-simplify-unaligned-ref branch 2 times, most recently from 971c23f to 673a809 Compare September 5, 2023 20:03
jswrenn
jswrenn previously approved these changes Sep 6, 2023
src/lib.rs Outdated
Comment on lines 1948 to 1951
#[inline]
pub fn new_unaligned(bytes: B) -> Option<Ref<B, T>> {
if bytes.len() != mem::size_of::<T>() {
return None;
}
Some(Ref(bytes, PhantomData))
Ref::new(bytes)
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since these methods just become aliases for their non-unaligned counterparts, what's the rationale for keeping them? If it's just to minimize immediate breakage, I'd suggest that they are mark deprecated and removed from a future release.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's to minimize breakage, yeah. I don't want to mark them as deprecated yet for two reasons:

  • Without deprecating them, this is a breaking change [1]
  • I'm not convinced we'll actually want to get rid of them; there's more work to be done around how our API expresses what is and isn't validated at runtime, and I could see a future in which we keep these and have them return a different error type than the constructors that need to check alignment

I've filed #338 to track this.

[1] At some point I want to come up with a more unified story around how we keep track of "pending breaking changes". It'd be good to be able to say "this is a breaking change we'll make as soon as we're ready to release e.g. 0.8." We have that loosely tracked in issues right now, but it's neither consistent nor enforced.

These constructors don't currently make use of the `T: Unaligned` bound
internally - they just use it to document that an alignment check is
guaranteed to be elided. The alignment check in the non-`Unaligned`
constructors is trivially optimizable when it's unneeded since it's just
a check that `x % 1 == 0`. For that reason, in this commit, we remove
these methods' internals and simply have them be wrappers around the
equivalent non-`Unaligned` constructors.

While we're here, mark `Ref` functions which are just thin wrappers
around other functions as `#[inline(always)]`.
@joshlf joshlf force-pushed the known-layout-1-simplify-unaligned-ref branch from 673a809 to d97190e Compare September 6, 2023 15:53
@joshlf joshlf enabled auto-merge (squash) September 6, 2023 15:54
@joshlf
Copy link
Member Author

joshlf commented Sep 6, 2023

Looks like pushing new changes removed your approval, sorry. Can you re-approve?

@joshlf joshlf requested a review from jswrenn September 6, 2023 15:55
@joshlf joshlf merged commit 80455a9 into main Sep 6, 2023
@joshlf joshlf deleted the known-layout-1-simplify-unaligned-ref branch September 6, 2023 17:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants