Possible approach to fix #71

[steffahn]

Resolves #71.

[steffahn]

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.

[Ten0]

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

[Ten0]

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).

[Ten0]

Actually that seems to have been an error by the std : https://github.com/rust-lang/rust/blob/ff8c8dfbe66701531e3e5e335c28c544d0fbc945/library/core/src/cell.rs#L1332-L1335

rust-lang/rust#97027

[Ten0]

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).