{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreie23nuqllgegquktemwv3e6efa6zedkeyf7aef5ayqy7dr3dzxkzu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mggqxikhwi42"
  },
  "path": "/t/testing-the-waters-umcs-unified-method-call-syntax/24014?page=2#post_28",
  "publishedAt": "2026-03-07T00:07:20.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Idea: Paths in method names",
    "language design",
    "Once again",
    "adding methods and people getting broken",
    "Top-level self functions `fn f(self: T)`"
  ],
  "textContent": "Ratatouille:\n\n> whether there is enough need for supporting multiple arguments to warrant special syntax\n\nFor disambiguation: It's known to me there is a need for it \"when a conflict happens\"\n\nIdea: Paths in method names language design\n\n> Once again, we have a case in std of adding methods and people getting broken. I really don’t want to get stuck in the sad world where we can no longer add things without new a new extension trait every time, so I want to keep this allowed breakage, but maybe there’s a way we can make it a bit less annoying. Right now, the answer to getting the wrong method is UFCS. That certainly works, but there’s a massive gulf here—to control name resolution you need to give up on method syntax entirely, …\n\nFor chaining style: I don't know.\n\nBesides these, there's a previous topic suggesting this has been wanted before, and can be an improvement of life, like being a concise replacement for extension trait pattern mentioned earlier in this thread too, having better IDE autocomplete, and avoiding what some people believe to be \"deref anti-patterns\"not able to get my head around it\n\nTop-level self functions `fn f(self: T)` language design\n\n> Since inherent impls are not allowed from external crates, I find myself making traits just to be able to dot-off some object e.g. obj.f(), and falling back to fn f(this: T) when it's too much code for little gain because the function signature has to be duplicated. I think being able to write top-level fn f(self: T) functions can lead to cleaner code while not overloading impl syntax just for this purpose.",
  "title": "Testing the waters: UMCS (Unified Method Call Syntax)"
}