Testing the waters: UMCS (Unified Method Call Syntax)

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 language design

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, …

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) language design

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.