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

Make the inner type wrapped in Unalign public #836

Open
ChayimFriedman2 opened this issue Feb 3, 2024 · 2 comments
Open

Make the inner type wrapped in Unalign public #836

ChayimFriedman2 opened this issue Feb 3, 2024 · 2 comments

Comments

@ChayimFriedman2
Copy link

This is not exactly a customer request since I'm not using this crate currently, but I was looking on the docs and I wondered why won't you make the inner field of Unalign public?

Usually when prefer to make newtype's field private, but in this case making it public has a big advantage: we cannot make a reference to it and so we cannot expose it in a non-copying way, but if it is public the compiler allows reads/writes to fields of it as long as we never take a reference and only read/write directly. This can make working with this type more comfortable.

jswrenn added a commit that referenced this issue Mar 27, 2024
This allows for directly writing to the field safely. Since Rust
ensures that unsafe uses of this field require `unsafe`, we should
additionally consider deprecating many of the methods of `Unalign`.

Fixes #836
jswrenn added a commit that referenced this issue Mar 27, 2024
This allows for directly writing to the field safely. Since Rust
ensures that unsafe uses of this field require `unsafe`, we should
additionally consider deprecating many of the methods of `Unalign`.

Fixes #836
@joshlf
Copy link
Member

joshlf commented Mar 27, 2024

I'm concerned that this will back us into a corner. In particular, there's a chance that we may want to support unsized Unalign types in the future (i.e., Unalign<T: ?Sized>) (#209). We probably can't do that without some heavy type machinery that might require changing the fields of Unalign to "manually reconstruct" the layout we're trying to build. (This comes from various limitations regarding repr(packed) with unsized types.)

I agree that there's a minor ergonomic benefit with making the inner field public, but are there any patterns that can't be expressed with our existing API and methods? If it's just an ergonomic thing, I'm inclined to not do this right now, but if it's an expressibility issue, then that's a different story.

@joshlf
Copy link
Member

joshlf commented Mar 27, 2024

Note that #1076 implements this. I've closed it, but we can re-open if we decide to move forward with this.

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 a pull request may close this issue.

2 participants