-
Notifications
You must be signed in to change notification settings - Fork 81
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
Bikeshed the name of our NoCell
trait
#994
Comments
I'm partial to This is advantage over |
NoCell
trait.NoCell
trait
I personally find the name Because
Not just shared aliasing (being when two
One issue I have with this (and most of these names) is that the constraint is only for the struct itself containing an Some proposals I've seen put the word "shallow" in to disambiguate, but again that makes the trait name even longer. |
Can you say more about this distinction? I'm not sure what you're referring to.
I agree that this is a problem, although I'll note that |
Agreed, though I'd (weakly) argue it's to a lesser degree. It refers to the presence of a particular struct rather than whether state can be shared-mutated, and I'd suggest that makes it less likely to conflate I've been thinking about the "shallow" qualifier too, and it has its own problem: shallow could mean "no pointer indirection" or it could mean "is not wrapped in another type". Same with "direct" and "plain". Some other qualifier ideas:
It's (pedantic) pushback on using the term "aliasing" for all |
We selected `Immutable` on @rcoh's suggestion that our name for this be a single, evocative word, like `Send` and `Sync`. As with `Send` and `Sync`, we do not hope that `Immutable`, on its own, captures the entire semantics of this trait; the burden of entirely capturing its semantics rests on its documentation. We are not overly concerned with the risk of future conflict with Rust. If and when Rust stabilizes its own version of this trait, we will adjust zerocopy to use Rust's trait instead. Closes #994
We selected `Immutable` on @rcoh's suggestion that our name for this be a single, evocative word, like `Send` and `Sync`. As with `Send` and `Sync`, we do not hope that `Immutable`, on its own, captures the entire semantics of this trait; the burden of entirely capturing its semantics rests on its documentation. We are not overly concerned with the risk of future conflict with Rust. If and when Rust stabilizes its own version of this trait, we will adjust zerocopy to use Rust's trait instead. Closes #994
We selected `Immutable` on @rcoh's suggestion that our name for this be a single, evocative word, like `Send` and `Sync`. As with `Send` and `Sync`, we do not hope that `Immutable`, on its own, captures the entire semantics of this trait; the burden of entirely capturing its semantics rests on its documentation. We are not overly concerned with the risk of future conflict with Rust. If and when Rust stabilizes its own version of this trait, we will adjust zerocopy to use Rust's trait instead. Closes #994
We selected `Immutable` on @rcoh's suggestion that our name for this be a single, evocative word, like `Send` and `Sync`. As with `Send` and `Sync`, we do not hope that `Immutable`, on its own, captures the entire semantics of this trait; the burden of entirely capturing its semantics rests on its documentation. We are not overly concerned with the risk of future conflict with Rust. If and when Rust stabilizes its own version of this trait, we will adjust zerocopy to use Rust's trait instead. Closes #994
Related to #251.
Possibilities:
Freeze
NoCell
InteriorImmutable
SharedImmutable
NoInteriorMutability
The text was updated successfully, but these errors were encountered: