Method auto-(de)ref (and lack of it) in RFC 132 ufcs

I was a bit upset at RFC 132 for not having auto-(de)ref for recievers.

After some research I found:

• Method auto-ref on the dot operator is present around the time of RFC 132 (evidence: code examples in RFC 241). I don't know why its lack in RFC 132 isn't noted at all in the RFC PR. Perhaps RFC processes were just not popular enough then? But I can't find anything in the 0.11.0 reference about method auto-ref on the dot operator, so maybe that feature is just altogether under-noted back then.

• Method auto-de ref semantics is added after RFC 132, so they naturally weren't considered then.

So I guess if #241 deref-conversions was there back then, and method auto-ref semantics were properly documented, then #132 ufcs would have considered it, e.g. add auto-(de)ref for it in T::method(it, ...) where fn method(&self, ...) Self = T][[1], allowing it to compile with it: Box<T>.

So it seems that ufcs lacking auto-(de)ref is just a historical problem, not something intended.

I guess ufcs (and method disambiguation in general2]) is kinda rare such that people know it but haven't bothered enough to write an RFC for it. (There is RFC 3913, actually. ([Pre-RFC)) And ufcs has been there for 10+ years such that its characteristic of lacking auto-(de)ref might have even been relied on. These are all my guesses because I don't use it often too. What do you think of these? Do you have experiences that prove or disprove these statements? And what do you think about adding auto-(de)ref to ufcs now?

1. method may be on T or on a trait, should be the same anyway ↩︎

2. including e.g. this pub trait Quz hack ↩︎