-
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
Relax Immutable
semantics
#1155
Comments
This PR adjust's `Immutable`'s informal public contract. Previously, we publicly documented that `Immutable` denoted that a type does not directly contain `UnsafeCell`. Now, we only document that `Immutable` types do not permit interrior mutation. This change is made in recognition that: - Containing `UnsafeCell` may be fine, so long as that the special properties of that `UnsafeCell` cannot be exercised in safe code. - In contrast to what's guaranteed by the compiler's `Freeze` trait, we almost certainly need *recursive* immutability for safe transmutation. Makes progress towards #1155.
This PR adjust's `Immutable`'s informal public contract. Previously, we publicly documented that `Immutable` denoted that a type does not directly contain `UnsafeCell`. Now, we only document that `Immutable` types do not permit interrior mutation. This change is made in recognition that: - Containing `UnsafeCell` may be fine, so long as that the special properties of that `UnsafeCell` cannot be exercised in safe code. - In contrast to what's guaranteed by the compiler's `Freeze` trait, we almost certainly need *recursive* immutability for safe transmutation. Makes progress towards #1155.
This PR adjust's `Immutable`'s informal public contract. Previously, we publicly documented that `Immutable` denoted that a type does not directly contain `UnsafeCell`. Now, we only document that `Immutable` types do not permit interrior mutation. This change is made in recognition that: - Containing `UnsafeCell` may be fine, so long as that the special properties of that `UnsafeCell` cannot be exercised in safe code. - In contrast to what's guaranteed by the compiler's `Freeze` trait, we almost certainly need *recursive* immutability for safe transmutation. Makes progress towards #1155.
This PR adjust's `Immutable`'s informal public contract. Previously, we publicly documented that `Immutable` denoted that a type does not directly contain `UnsafeCell`. Now, we only document that `Immutable` types do not permit interrior mutation. This change is made in recognition that: - Containing `UnsafeCell` may be fine, so long as that the special properties of that `UnsafeCell` cannot be exercised in safe code. - In contrast to what's guaranteed by the compiler's `Freeze` trait, we almost certainly need *recursive* immutability for safe transmutation. Makes progress towards #1155.
@joshlf I'm a little confused why we need the different semantics from
It will be Second unrelated question: do we need a EDIT: Are the current bounds related to rust-lang/unsafe-code-guidelines#495 ? |
TLDR: You've prompted @jswrenn and me to reconsider, and we might actually go back to considering The reason has to do with future compatibility with safe transmute, which will permit The reason we've considered walking this back is that safe transmute will have its own trait (such as this one) which is completely separate from
Exactly. In particular:
|
Overview
Progress
Immutable
documentation so that it requires recursive freedom from interior mutability, not just shallowImmutable
documentation so that it refers only to interior mutabilityImmutable
documentation so that it promises nothing to callers outside of zerocopyFreeze
is stabilized, consider whether or notImmutable
needs to have the same semantics asFreeze
Freeze
is stabilized, add section toImmutable
documentation entitled something like "Why notFreeze
?"UnsafeCell
s exist at certain offsets or covering certain rangesImmutable
documentation to refer to this formal notion of interior mutabilityUnsafeCell
s in some places as appropriate (e.g., introduce a wrapper type which "disables" interior mutability)Details
Intuitive definition of interior mutability + compiler optimizations
TODO:
Interior mutability vs
UnsafeCell
sTODO: Describe how interior mutability is implemented via
UnsafeCell
s today, and justify our intention to relaxImmutable
's requirements in the future to only mention interior mutability, notUnsafeCell
s in particular.Stacked Borrows,
UnsafeCell
overlap, and Ralf's future plansTODO:
UnsafeCell
overlapImmutable
vsFreeze
EDIT: Maybe not? #1155 (comment)
TODO:
Immutable
must be recursive, while the stdlibFreeze
will not be recursiveImmutable
withFreeze
The text was updated successfully, but these errors were encountered: