# Testing the waters: UMCS (Unified Method Call Syntax)

**URL:** <https://internals.rust-lang.org/t/testing-the-waters-umcs-unified-method-call-syntax/24014>\
**Category:** language design\
**Created:** [February 15, 2026, 12:15pm UTC](https://internals.rust-lang.org/t/testing-the-waters-umcs-unified-method-call-syntax/24014 "2026-02-15T12:15:47Z")\
**Posts on this page:** 1\
**Showing post:** 28

<div class="post-metadata">

**Author:** ![bettertree](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bettertree/32/14062_2.png) [@bettertree](https://internals.rust-lang.org/u/bettertree)\
**Post date:** [March 7, 2026, 12:07am UTC](https://internals.rust-lang.org/t/testing-the-waters-umcs-unified-method-call-syntax/24014/28 "2026-03-07T00:07:20Z")

</div>

> [@Ratatouille](#):
>
> whether there is enough need for supporting multiple arguments to warrant special syntax

For disambiguation: It's known to me there is a need for it "when a conflict happens"

> [@Idea: Paths in method names](https://internals.rust-lang.org/t/idea-paths-in-method-names/6834):
>
> [Once again](https://github.com/rust-lang/rust/pull/42496#issuecomment-320448055), we have a case in std of [adding methods and people getting broken](https://github.com/rust-lang/rust/pull/48115#issuecomment-368389326). 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, …

For chaining style: I don't know.

Besides 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

> [@Top-level self functions \`fn f(self: T)\`](https://internals.rust-lang.org/t/top-level-self-functions-fn-f-self-t/23620):
>
> 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.

---

_[View the full topic](https://internals.rust-lang.org/t/testing-the-waters-umcs-unified-method-call-syntax/24014)._