{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihk52kfcrvxtixif4ilsfttu2yx4rmr5lnc2iurtsoawn6tbrp7pi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfqy443q75s2"
  },
  "path": "/t/pre-pre-rfc-splatting-for-named-arguments-and-function-overloading/24012?page=2#post_39",
  "publishedAt": "2026-02-26T08:50:19.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "> If all \"overload\" implementations must have \"**same argument name = > same type or same bounds**\", how would that make type inference any more difficult?\n\nMy OP proposal does not include that, nor do I know how we'd impose that in the trait system. I do see that others have proposed it but idk how that would work.\n\n> But as far as I can tell many don't want that (except perhaps for FFI compatibility).\n\nC++ FFI is my main motivation for having any kind of overloading. I don't particularly want overloading in the language outside of that, it just so happened that there was a tiny-looking syntactic feature that would give it \"for free\".\n\n> If the splatted trait is not sealed, can any crate add new \"overloads\" to the function?\n\nYou can only splat a generic that implements `Tuple`, which is only implemented for built-in tuples, so only the crate that defines the trait can define impls for it, unless I'm forgetting some piece of orphan rules magic.",
  "title": "[Pre-pre-RFC] \"splatting\" for named arguments and function overloading"
}