{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiawknw5jxwfdjekpk66s7z43i653yhlmifea3myzjy232feef73yy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfpwjaei4wo2"
  },
  "path": "/t/method-auto-de-ref-and-lack-of-it-in-rfc-132-ufcs/24005#post_9",
  "publishedAt": "2026-02-26T00:22:04.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "auto-borrowing was removed",
    "appendix"
  ],
  "textContent": "I accidentally kind of buried a lede in my previous post. To directly answer the OP question, you need to look into prehistory a bit. RFC 241 includes a section:\n\n> When auto-borrowing was removed, this reasoning difficulty was cited as a major motivator:\n>\n>> Code readability does not necessarily benefit from autoref on arguments:\n>\n>\n>     let a = ~Foo;\n>     foo(a); // reading this code looks like it moves `a`\n>     fn foo(_: &Foo) {} // ah, nevermind, it doesn't move `a`!\n>\n>     let mut a = ~[ ... ];\n>     sort(a); // not only does this not move `a`, but it mutates it!\n>\n>\n> Having to include an extra `&` or `&mut` for arguments is a slight inconvenience, but it makes it much easier to track ownership at a glance. (Note that ownership is not _entirely_ explicit, due to `self` and macros; see the appendix.)\n>\n> This RFC takes as a basic principle: **Coercions should never implicitly borrow from owned data**.\n>\n> [...]\n>\n> In today’s Rust, ownership transfer/borrowing is explicit for all function/method arguments. It is implicit only for:\n>\n>   * _self on method invocations._ In practice, the name and context of a method invocation is almost always sufficient to infer its move/borrow semantics.\n>\n>   * _Macro invocations._ Since macros can expand into arbitrary code, macro invocations can appear to move when they actually borrow.\n>\n>\n\n\nThis can let us infer that at the time autoref was directly tied to `&[mut] self` receivers for method invocation. I'd hazard a guess that the ability to select `<&T>::method` on a receiver of type `T` was not a designed capability but was just a side effect of the implementation choices. Notably, the self lookup process was described as some number of autoderef followed by a single autoref; it makes sense for that autoref to be for the `Self` to `&Self` coercion.",
  "title": "Method auto-(de)ref (and lack of it) in RFC 132 ufcs"
}