# 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