{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiayyemxz2sxyvy42gass2b4vkw32w5aix6krhrbwfwmke6cfq2ema",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mewyccvjkju2"
  },
  "path": "/t/testing-the-waters-umcs-unified-method-call-syntax/24014#post_4",
  "publishedAt": "2026-02-15T19:10:34.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "I'm still fond of this idea. Imho, it does feel a bit weird, but so did postfix `.await` initially; I think that this style of unified method call syntax would feel similarly natural in retrospect, but will be a difficult sell until people start\n\nkornel:\n\n> One thing I'm concerned about: is this currying?\n\n`receiver.(function)()` should not be currying, exactly because `receiver.method()` is not curried. The behavior of `$place.($fn)($args)` is exactly to call `($fn)($place, $args)` while applying the same receiver autoref coercions that apply to `$place.$method($args)`. The _**only**_ difference is that the traditional method syntax looks in the associated method namespace and in the unified method call syntax `$fn` is an arbitrary expression evaluating to some `impl Fn*` (eg a function item or closure).\n\nThe only involvement of currying is that you can get close to faking the syntax with `place.p(func)(args)` by currying, but you lose out on mut-generic autoref and two-phase borrows.",
  "title": "Testing the waters: UMCS (Unified Method Call Syntax)"
}