Deref to type that is also a Receiver to the original type creates an infinite cycle

[tmandry]

Let's say I define a transparent receiver type like this:

#[repr(transparent)]
struct CRef<T> {
    inner: T,
}

impl<T> Receiver for CRef<T> {
    type Target = T;
}

And then a type which allows "viewing" itself as a &CRef<T> when what you have is a &T:

#[repr(C)]
struct Flag(i32);

impl Deref for Flag {
    type Target = CRef<Flag>;
    fn deref(&self) -> &Self::Target {
        unsafe { &*(self as *const _ as *const CRef<Self>) }
    }
}

Then given this:

impl Flag {
    fn get(self: &CRef<Self>) -> i32 { 42 }
}

fn main() {
    let flag = Flag(0);
    assert_eq!(flag.get(), 42);
}

I expect flag.get() to mean something like

let flagcr: &CRef<Flag> = <Flag as Deref>::deref(&flag);
Flag::get(flagcr)

but instead I got

error[E0055]: reached the recursion limit while auto-dereferencing `CRef<Flag>`
  --> src/main.rs:32:21
   |
32 |     assert_eq!(flag.get(), 42);
   |                     ^^^ deref recursion limit reached
   |
   = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`playground`)

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=e3e560589bf664d37a489d798f41cca5

It's possible this is somehow correct and there's no way to do what I'm trying to do, but if it is I don't see why.

[compiler-errors]

This is not a bug. This produces a receiver chain that goes Flag -> CRef<Flag> -> Flag -> ... which is an infinite set of types.

[tmandry]

@compiler-errors I see how that's an infinite chain, but I don't see how it's an infinite set. There are only two types. Are you saying it's the interaction with autoref that produces an infinite set of types?

[compiler-errors]

Autoderef doesn't deduplicate infinite chains of types if they have closed cycles.

This could be hacked around, but I'd probably discourage it, since this would be problematic, for example, as soon as we had things like type and lifetime variables in the types, since it's pretty easy to construct a chain of types that differ only by inference variables which are yet unresolved.

[compiler-errors]

All autoderef does is repeatedly apply <TY as Receiver>::Target and normalize that type. So to autoderef there are an infinite set of types, since it doesn't care if these types have any sort of reoccurrence relationship.

[tmandry]

Ok, thanks for answering my questions!

To summarize, it would be difficult to do cycle detection because of the possible presence of type variables. Maybe some kind of canonicalization could work if we had to solve this. But we don't really: The Deref impl is a hack to simulate a form of custom autoref, which could be modeled in a more first-class way, albeit only with new language features.