Support generic pointer framework and generic pointer casts #1183
Assignees
Comments
This was referenced May 3, 2024
This was referenced May 7, 2024
joshlf
added a commit
that referenced
this issue
Oct 12, 2024
Previously, we supported the `AtLeast` bound, which was used to describe a subset relationship in which `I: AtLeast<J>` implied that `I` as at least as restrictive as `J`. However, as described in #1866, this incorrectly models invariants as monotonic. In reality, invariants both provide guarantees but also *require* guarantees. This commit takes a step in the direction of resolving #1866 by removing `AtLeast`. Uses of `AtLeast<Shared>` are replaced by a new `Reference` trait, which is implemented for `Shared` and `Exclusive`. This serves two purposes: First, it makes it explicit what this bound means. Previously, `AtLeast<Shared>` had an ambiguous meaning, while `Reference` means precisely that an invariant is either `Shared` or `Exclusive` and nothing else. Second, it paves the way for #1183, in which we may add new aliasing invariants which convey ownership. In that case, it will be important for existing methods to add `Reference` bounds when those methods would not be sound in the face of ownership semantics. We also inline the items in the `invariant` module, which were previously generated by macro. The addition of the `Reference` trait did not play nicely with that macro, and we will likely need to go further from the macro in order to fix #1839 – this fix will likely require making aliasing invariants meaningfully different than other invariants, for example by adding an associated type. Makes progress on #1866
joshlf
added a commit
that referenced
this issue
Oct 12, 2024
Previously, we supported the `AtLeast` bound, which was used to describe a subset relationship in which `I: AtLeast<J>` implied that `I` as at least as restrictive as `J`. However, as described in #1866, this incorrectly models invariants as monotonic. In reality, invariants both provide guarantees but also *require* guarantees. This commit takes a step in the direction of resolving #1866 by removing `AtLeast`. Uses of `AtLeast<Shared>` are replaced by a new `Reference` trait, which is implemented for `Shared` and `Exclusive`. This serves two purposes: First, it makes it explicit what this bound means. Previously, `AtLeast<Shared>` had an ambiguous meaning, while `Reference` means precisely that an invariant is either `Shared` or `Exclusive` and nothing else. Second, it paves the way for #1183, in which we may add new aliasing invariants which convey ownership. In that case, it will be important for existing methods to add `Reference` bounds when those methods would not be sound in the face of ownership semantics. We also inline the items in the `invariant` module, which were previously generated by macro. The addition of the `Reference` trait did not play nicely with that macro, and we will likely need to go further from the macro in order to fix #1839 – this fix will likely require making aliasing invariants meaningfully different than other invariants, for example by adding an associated type. Makes progress on #1866
joshlf
added a commit
that referenced
this issue
Oct 12, 2024
Previously, we supported the `AtLeast` bound, which was used to describe a subset relationship in which `I: AtLeast<J>` implied that `I` as at least as restrictive as `J`. However, as described in #1866, this incorrectly models invariants as monotonic. In reality, invariants both provide guarantees but also *require* guarantees. This commit takes a step in the direction of resolving #1866 by removing `AtLeast`. Uses of `AtLeast<Shared>` are replaced by a new `Reference` trait, which is implemented for `Shared` and `Exclusive`. This serves two purposes: First, it makes it explicit what this bound means. Previously, `AtLeast<Shared>` had an ambiguous meaning, while `Reference` means precisely that an invariant is either `Shared` or `Exclusive` and nothing else. Second, it paves the way for #1183, in which we may add new aliasing invariants which convey ownership. In that case, it will be important for existing methods to add `Reference` bounds when those methods would not be sound in the face of ownership semantics. We also inline the items in the `invariant` module, which were previously generated by macro. The addition of the `Reference` trait did not play nicely with that macro, and we will likely need to go further from the macro in order to fix #1839 – this fix will likely require making aliasing invariants meaningfully different than other invariants, for example by adding an associated type. Makes progress on #1866
joshlf
added a commit
that referenced
this issue
Oct 14, 2024
Previously, we supported the `AtLeast` bound, which was used to describe a subset relationship in which `I: AtLeast<J>` implied that `I` as at least as restrictive as `J`. However, as described in #1866, this incorrectly models invariants as monotonic. In reality, invariants both provide guarantees but also *require* guarantees. This commit takes a step in the direction of resolving #1866 by removing `AtLeast`. Uses of `AtLeast<Shared>` are replaced by a new `Reference` trait, which is implemented for `Shared` and `Exclusive`. This serves two purposes: First, it makes it explicit what this bound means. Previously, `AtLeast<Shared>` had an ambiguous meaning, while `Reference` means precisely that an invariant is either `Shared` or `Exclusive` and nothing else. Second, it paves the way for #1183, in which we may add new aliasing invariants which convey ownership. In that case, it will be important for existing methods to add `Reference` bounds when those methods would not be sound in the face of ownership semantics. We also inline the items in the `invariant` module, which were previously generated by macro. The addition of the `Reference` trait did not play nicely with that macro, and we will likely need to go further from the macro in order to fix #1839 – this fix will likely require making aliasing invariants meaningfully different than other invariants, for example by adding an associated type. Makes progress on #1866
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 14, 2024
Previously, we supported the `AtLeast` bound, which was used to describe a subset relationship in which `I: AtLeast<J>` implied that `I` as at least as restrictive as `J`. However, as described in #1866, this incorrectly models invariants as monotonic. In reality, invariants both provide guarantees but also *require* guarantees. This commit takes a step in the direction of resolving #1866 by removing `AtLeast`. Uses of `AtLeast<Shared>` are replaced by a new `Reference` trait, which is implemented for `Shared` and `Exclusive`. This serves two purposes: First, it makes it explicit what this bound means. Previously, `AtLeast<Shared>` had an ambiguous meaning, while `Reference` means precisely that an invariant is either `Shared` or `Exclusive` and nothing else. Second, it paves the way for #1183, in which we may add new aliasing invariants which convey ownership. In that case, it will be important for existing methods to add `Reference` bounds when those methods would not be sound in the face of ownership semantics. We also inline the items in the `invariant` module, which were previously generated by macro. The addition of the `Reference` trait did not play nicely with that macro, and we will likely need to go further from the macro in order to fix #1839 – this fix will likely require making aliasing invariants meaningfully different than other invariants, for example by adding an associated type. Makes progress on #1866
joshlf
added a commit
that referenced
this issue
Oct 14, 2024
Previously, we supported the `AtLeast` bound, which was used to describe a subset relationship in which `I: AtLeast<J>` implied that `I` as at least as restrictive as `J`. However, as described in #1866, this incorrectly models invariants as monotonic. In reality, invariants both provide guarantees but also *require* guarantees. This commit takes a step in the direction of resolving #1866 by removing `AtLeast`. Uses of `AtLeast<Shared>` are replaced by a new `Reference` trait, which is implemented for `Shared` and `Exclusive`. This serves two purposes: First, it makes it explicit what this bound means. Previously, `AtLeast<Shared>` had an ambiguous meaning, while `Reference` means precisely that an invariant is either `Shared` or `Exclusive` and nothing else. Second, it paves the way for #1183, in which we may add new aliasing invariants which convey ownership. In that case, it will be important for existing methods to add `Reference` bounds when those methods would not be sound in the face of ownership semantics. We also inline the items in the `invariant` module, which were previously generated by macro. The addition of the `Reference` trait did not play nicely with that macro, and we will likely need to go further from the macro in order to fix #1839 – this fix will likely require making aliasing invariants meaningfully different than other invariants, for example by adding an associated type. Makes progress on #1866
joshlf
added a commit
that referenced
this issue
Feb 24, 2025
Previously, we supported the `AtLeast` bound, which was used to describe a subset relationship in which `I: AtLeast<J>` implied that `I` as at least as restrictive as `J`. However, as described in #1866, this incorrectly models invariants as monotonic. In reality, invariants both provide guarantees but also *require* guarantees. This commit takes a step in the direction of resolving #1866 by removing `AtLeast`. Uses of `AtLeast<Shared>` are replaced by a new `Reference` trait, which is implemented for `Shared` and `Exclusive`. This serves two purposes: First, it makes it explicit what this bound means. Previously, `AtLeast<Shared>` had an ambiguous meaning, while `Reference` means precisely that an invariant is either `Shared` or `Exclusive` and nothing else. Second, it paves the way for #1183, in which we may add new aliasing invariants which convey ownership. In that case, it will be important for existing methods to add `Reference` bounds when those methods would not be sound in the face of ownership semantics. We also inline the items in the `invariant` module, which were previously generated by macro. The addition of the `Reference` trait did not play nicely with that macro, and we will likely need to go further from the macro in order to fix #1839 – this fix will likely require making aliasing invariants meaningfully different than other invariants, for example by adding an associated type. Makes progress on #1866 gherrit-pr-id: I86ef959643b97a34da81bf55a1fed5060b9cf6b2
joshlf
added a commit
that referenced
this issue
Feb 24, 2025
Previously, we supported the `AtLeast` bound, which was used to describe a subset relationship in which `I: AtLeast<J>` implied that `I` as at least as restrictive as `J`. However, as described in #1866, this incorrectly models invariants as monotonic. In reality, invariants both provide guarantees but also *require* guarantees. This commit takes a step in the direction of resolving #1866 by removing `AtLeast`. Uses of `AtLeast<Shared>` are replaced by a new `Reference` trait, which is implemented for `Shared` and `Exclusive`. This serves two purposes: First, it makes it explicit what this bound means. Previously, `AtLeast<Shared>` had an ambiguous meaning, while `Reference` means precisely that an invariant is either `Shared` or `Exclusive` and nothing else. Second, it paves the way for #1183, in which we may add new aliasing invariants which convey ownership. In that case, it will be important for existing methods to add `Reference` bounds when those methods would not be sound in the face of ownership semantics. We also inline the items in the `invariant` module, which were previously generated by macro. The addition of the `Reference` trait did not play nicely with that macro, and we will likely need to go further from the macro in order to fix #1839 – this fix will likely require making aliasing invariants meaningfully different than other invariants, for example by adding an associated type. Makes progress on #1866 gherrit-pr-id: I86ef959643b97a34da81bf55a1fed5060b9cf6b2
github-merge-queue bot
pushed a commit
that referenced
this issue
Feb 24, 2025
Previously, we supported the `AtLeast` bound, which was used to describe a subset relationship in which `I: AtLeast<J>` implied that `I` as at least as restrictive as `J`. However, as described in #1866, this incorrectly models invariants as monotonic. In reality, invariants both provide guarantees but also *require* guarantees. This commit takes a step in the direction of resolving #1866 by removing `AtLeast`. Uses of `AtLeast<Shared>` are replaced by a new `Reference` trait, which is implemented for `Shared` and `Exclusive`. This serves two purposes: First, it makes it explicit what this bound means. Previously, `AtLeast<Shared>` had an ambiguous meaning, while `Reference` means precisely that an invariant is either `Shared` or `Exclusive` and nothing else. Second, it paves the way for #1183, in which we may add new aliasing invariants which convey ownership. In that case, it will be important for existing methods to add `Reference` bounds when those methods would not be sound in the face of ownership semantics. We also inline the items in the `invariant` module, which were previously generated by macro. The addition of the `Reference` trait did not play nicely with that macro, and we will likely need to go further from the macro in order to fix #1839 – this fix will likely require making aliasing invariants meaningfully different than other invariants, for example by adding an associated type. Makes progress on #1866 gherrit-pr-id: I86ef959643b97a34da81bf55a1fed5060b9cf6b2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Overview
This design is prototyped in #1169, #1209, #1345, and #1355.
Note that this design will likely require GAT, which isn't stable on our 0.8 MSRV (1.56).
A generic
trait Pointer<'a, T>with an associated type,type Pointer<'b, U>, which represents the same pointer type applied to a different referent type. E.g.,impl<'a, T> Pointer<'a, T> for &'a T { type Pointer<'b, U> = &'b U; }.Permits conversion code to be generic over pointer type. For example, instead of needing
FromBytes::ref_from_bytes,mut_from_bytes, and a hypothetical futurebox_from_bytes(and similar for other container types - see #114), we could write a singleFromBytes::from_bytesthat would be generic over pointer type, unifying the source and destination pointer types (e.g.,&[u8] -> &T,&mut [u8] -> &mut T, etc).Progress
Note that the first steps do not commit us to any public API, and so can be done without concern to semver.
Deref/DerefMutbounds in here somewhere?FromPtr/IntoPtrinternally (these don't require GAT, and so work on our MSRV); use to deduplicate internal helper code suchref_from_prefix_suffixandmut_from_prefix_suffixPointerinRef's APIPointertypes that can be split (required forFromBytes::from_prefix) and those that cannot (e.g.Box)FromBytes::read_from_bytesandFromBytes::read_from_prefixPointertrait internally (either#[doc(hidden)]or pub-in-priv)Pointerrequires GAT, this will need to be version-gated as prototyped in #1345Requirements
FromZeros::new_pointer_zeroed<P: Pointer<Self>>() -> PFromBytes::from_bytes<P: Pointer<[u8]>>(bytes: P) -> Result<P::Pointer<Self>, ...>FromBytes::from_prefix<P: Pointer<[u8]>>(bytes: P) -> Result<(P::Pointer<Self>, P), ...>P = Box<[u8]>FromBytes::read_from_bytes<P: Pointer<[u8]>>(bytes: P) -> Result<Self, ...>P = Box<[u8]>; might be able to supportP = Arc<[u8]>IntoBytes::as_bytes<P: Pointer<Self>>(self: P) -> P::Pointer<[u8]>transmute_ptr!/try_transmute_ptr!P: Pointerbound which is akin to a kind (e.g., representingBoxrather thanBox<T>)UdpPacket<P: Pointer>trait Pointer<T = ()>so thatP: Pointeris sugar forP: Pointer<()>Design
As prototyped most recently in #1345, the design has this shape. Note that this design has gaps - for example, it does not distinguish between
Pointertypes which can be split (e.g. to supportFromBytes::from_prefix) and those which can't (such asBox).This trait (or one with a similar design) would permit us to abstract over the type of pointer used to reference a particular type. It could support shared and exclusive references, but also smart pointer types such as
Box,Rc,Arc, and possibly evenVec.This has a number of advantages:
Boxet al)transmute_ref!family of macros, or at least to introduce a new macro that permits "container transmutation" (#114)RefPtrinvariantsPointerhas associated types for anAliasingandSourceinvariant. When converting from ap: P(whereP: Pointer) to aPtr, the resultingPtrhas the invariants(P::Aliasing, Aligned, Valid, P::Source).The aliasing invariant must be encoded because different pointer types have different aliasing modes - e.g., shared references and
Arcs conform to theSharedaliasing invariant, while mutable references andBoxes conform to theExclusivealiasing invariant.This design also introduces the new
Sourceinvariant on allPtrs. TheSourceencodes the pointer type that was used to generate aPtr, and is used as a bound to prove that it is sound to convert from aPtrback into its originalPointertype at some point in the future. It would not be sound, for example, to perform the following conversion:&mut T -> Ptr<T> -> Box<T>.The way this bound works in practice is that it bounds implementations of the
FromPtrtrait. For example, here is the implementation ofFromPtr for Boxfrom #1345 (edited for brevity):Note: Previous designs (#1169 and #1209) did not have a separate
Sourceinvariant, and instead added newAliasinginvariants for eachPointertype (Aliasing = Box,Aliasing = Arc, etc). This has the disadvantage that all code which operates on aPtrmust understand whether the givenPointertype has shared- or exclusive-aliased semantics. By encoding theSourceas a separate invariant, we avoid this problem.VecWhile supporting
Vecdirectly may be hard, we can at least use the fact that the standard library supports conversion betweenVec<T>andBox<[T]>to build on top of ourBoxsupport.If we want to support
Vecdirectly, theVec -> Ptrdirection (Pointer) will be harder than thePtr -> Vec(FromPtrdirection. ForPtr -> Vec, we can useVec::from_raw_partsand pass the same capacity and size. However, going fromVec -> Ptr, we may be given aVecwhose size and capacity are not the same.Ptrdoes not currently have the ability to model such an allocation. The way thatVec -> Box(Vec::into_boxed_slice) handles this is by shrinking the underlying allocation to fit the size. This may be an expensive operation on some allocators.The text was updated successfully, but these errors were encountered: