# Tyler / Xiang # Nov, 2025 # Oct 23rd, 2025 ## Arbitrary self types ```rust // Crate core #[unstable_feature_bound(merge_chain)] impl<T: ?Sized + Deref> Receiver for T { type Target = <T as Deref>::Target; } // == CUT HERE == // Crate A - use multi-chain // NOTE: we are not applying `#![feature(merge_chain)]` feature gate here in A impl<T: ?Sized> Receiver for MyBox<T> { // conflicting impl with core type Target = T; } impl<T: ?Sized> Deref for MyBox<T> { type Target = Inner<T>; .. } impl<T> Inner<T> { fn method(&self) { .. } } struct AType; impl AType { fn method(self: MyBox<AType>) { .. } // this is preferred in case `??.method()` } let x: MyBox<AType>; x.method(); // this is resolved to `AType::method` // == CUT HERE == // Crate B - use single chain #![feature(merge_chain)] use a::{AType, MyBox}; impl MyStruct { fn method(self: MyBox<MyStruct>) { // WF error, `MyBox<MyStruct>` cannot receive `method` for `MyStruct` } } // also... let x: MyBox<AType>; x.method(); // this is resolved to `Inner::method` here in this crate ``` ### Experimentation problem We don't enough justification to split the chains. ### Philosophy of when to use deref / receiver Why use Receiver at all? * The containing type includes more information: Contracts, invariants, fields * e.g. pinned * Convenience We have types in std that are currently Deref but not Receiver * AssertUnwindSafe * `std::collections::binary_heap::PeekMut` * ... Why split target types? * We have some examples of where it's useful ### AIs - Eye patching, pretending that Deref -> Receiver exists without blanket impl - Write down the answer to the [philosophical question](https://hackmd.io/BZgRy4MFRq6HtYkpo_V5ow#The-use-case-matrix) in t-lang and ask for their opinions ## In-place init ### Various proposals, out-ptr solution #### Vibe check #### ## Evolving trait hierarchy https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/Evolving.20trait.20hierarchies.20.28goals.23393.29/near/546690945 ## Crubit