You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both transparent_wrapper_into_inner and as_bytes implement special cases of a generic Ptr<T> to Ptr<U> transmutation. This suggests that we could in theory support a more generic Ptr::transmute method, supported by a new TransmutableFrom trait. This trait would share some similarities with the built-in transmutability trait. However, as TransparentWrapper's support for invariant variance shows, it might be more powerful than that trait in certain ways.
In its most basic form, this API would look something like:
However, we will likely want to relax the Aligned and Valid requirements and post-conditions, and support a generic framework for mapping source invariants (on T) to destination invariants (on U) - essentially a generalization of what's currently supported with TransparentWrapper's invariant variance concept.
There may be multiple overlapping reasons to support transmuting a particular pair of types. For example, we could imagine the following impls:
Currently, these would result in an impl conflict. If #[marker] traits are stabilized, this won't be an issue - we can just mark TransmutableFrom as a #[marker] trait. Alternatively, we could use a dummy "reason" parameter to disambiguate, as we do with AliasingSafe today:
See also: #1122
Currently, we have a number of traits that express some aspect of transmutability:
TransparentWrapper
AliasingSafe
These, in turn, are used to bound certain
Ptr
transmutation methods, e.g.:transparent_wrapper_into_inner
as_bytes
try_cast_into
Both
transparent_wrapper_into_inner
andas_bytes
implement special cases of a genericPtr<T>
toPtr<U>
transmutation. This suggests that we could in theory support a more genericPtr::transmute
method, supported by a newTransmutableFrom
trait. This trait would share some similarities with the built-in transmutability trait. However, asTransparentWrapper
's support for invariant variance shows, it might be more powerful than that trait in certain ways.In its most basic form, this API would look something like:
However, we will likely want to relax the
Aligned
andValid
requirements and post-conditions, and support a generic framework for mapping source invariants (onT
) to destination invariants (onU
) - essentially a generalization of what's currently supported withTransparentWrapper
's invariant variance concept.There may be multiple overlapping reasons to support transmuting a particular pair of types. For example, we could imagine the following impls:
Currently, these would result in an impl conflict. If
#[marker]
traits are stabilized, this won't be an issue - we can just markTransmutableFrom
as a#[marker]
trait. Alternatively, we could use a dummy "reason" parameter to disambiguate, as we do withAliasingSafe
today:The text was updated successfully, but these errors were encountered: