{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiha4lqozbbd6lxyyj5q65lx2rmhvvftpo55lxo4u72wbmiwqxiwea",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfqy4ajo4ud2"
  },
  "path": "/t/pre-pre-rfc-splatting-for-named-arguments-and-function-overloading/24012?page=2#post_38",
  "publishedAt": "2026-02-26T08:42:15.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "[2]",
    "2] At that point type inference does not even depend on which arguments are present. [[3]",
    "↩︎"
  ],
  "textContent": "CAD97:\n\n> I'm quite iffy on splatting a function generic into its signature, since type inference seems like it would be a pain.\n\nAm I missing something here (in understanding)?\n\n  * If all \"overload\" [1] implementations must have \"**same argument name = > same type or same bounds**\", how would that make type inference any more difficult?\n  * That could be loosened to \"same argument name => same type or subset\" with specialization, but that shouldn't make type inference worse either, as at that point it is the same as with specialization.\n  * Only if it would be full C++-like overloading we get issues with type inference. But as far as I can tell many don't want that (except perhaps for FFI compatibility).\n\n\n\nWouldn't the same apply if there is only a single function that takes its named arguments in a struct? 2] At that point type inference does not even depend on which arguments are present. [[3]\n\nIf there is a trait that can be implemented by anyone, yes there would/could be many issues. But do we actually want/need that?\n\nOverloading with this \"same name same type\" restriction is probably enough (especially with specialization), as at that point it effectively just allows specialization over the list of arguments used (still not easy/trivial, yes). Or it can be seen as being generic over the set of present keys instead of just their types, which doesn't really make type inference worse from what I can tell, as long as the two are independent of each other and you can't rely on key isn't present so we must have tighter bounds so it must be this type (especially without specialization).\n\n* * *\n\n  1. Yes, slightly different problem, but related. I can almost guarantee that people (myself included) would want to combine splatting with specialization (which is effectively overloading with type restrictions). ↩︎\n\n  2. Though I'm still not convinced that is the best option for the \"many nearly-identical methods\" problem. ↩︎\n\n  3. Except for having to figure out what type the not-present arguments have to be. ↩︎\n\n\n",
  "title": "[Pre-pre-RFC] \"splatting\" for named arguments and function overloading"
}