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

Possible approach to fix #71 #72

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

steffahn
Copy link

@steffahn steffahn commented Jan 18, 2021

Resolves #71.

@steffahn
Copy link
Author

Only a draft since this does not explain the lifetime parameter in the documentation and since it isn’t clear whether an alternative solution with

pub struct OwningRef_<'t, O, T: ?Sized> {
    owner: O,
    reference: *const T,
    marker: PhantomData<&'t T>,
}
type OwningRef<O, T: ?Sized> = OwningRef_<'static, O, T>;

would be better (e.g. to reduce breakage). This would, effectlively, be like restricting OwningRef<O, T: ?Sized> to T: 'static (while also providing a more general version).

And it’s not clear what the best choice for more vs. less lifetime parameters for all the type synonyms is. This PR so far took the approach of avoiding implicit 'statics, but also avoiding confusion by having multiple type parameters for e.g. RefRef. Note that the type synonyms are for the common case only, so having them be somewhat restricted w.r.t. lifetimes would still allow people to use the underlying OwningRef/OwningRef_-based explicit type—with all the lifetimes—anyways.

Copy link

@Ten0 Ten0 left a comment

Choose a reason for hiding this comment

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

Regarding the no-implicit 'static I think I prefer this current approach as well.

Comment on lines 261 to +262
reference: *const T,
marker: PhantomData<&'t T>,
Copy link

Choose a reason for hiding this comment

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

The standard library takes the approach to store this as a single reference &'t T in Ref:
https://github.com/rust-lang/rust/blob/5a8a44196b3cf099f8c9b0156bd902eaec0b4e5f/library/core/src/cell.rs#L1286-L1289

Although the lifetime is still not correct by itself and we'd still have to downgrade it like we do when it's stored in PhantomData, it looks like it would not break anything and be closer to what it should be (reference can't be null, the compiler knows it if specified this way and can perform optimization based on that knowledge).

Copy link

@Ten0 Ten0 Nov 23, 2022

Choose a reason for hiding this comment

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

Comment on lines 276 to +277
reference: *mut T,
marker: PhantomData<&'t T>,
Copy link

Choose a reason for hiding this comment

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

The standard library takes the approach to store this as a single reference &'t mut T in RefMut:
https://github.com/rust-lang/rust/blob/5a8a44196b3cf099f8c9b0156bd902eaec0b4e5f/library/core/src/cell.rs#L1662-L1665

Although the lifetime is still not correct by itself and we'd still have to downgrade it like we do when it's stored in PhantomData, it looks like it would not break anything and be closer to what it should be (reference can't be null, the compiler knows it if specified this way and can perform optimization based on that knowledge).

@noamtashma noamtashma mentioned this pull request Jan 23, 2022
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.

OwningRef::map is unsound
2 participants