{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigzptciftadlg4v4dtk5brwfhmpw34ampniolmxcpwojjncx5gtka",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfqko6mgfpp2"
  },
  "path": "/t/pre-pre-rfc-splatting-for-named-arguments-and-function-overloading/24012?page=2#post_37",
  "publishedAt": "2026-02-26T05:24:06.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "`std::marker::Tuple`"
  ],
  "textContent": "Nadrieril:\n\n> It is allowed if `Type` is a struct or if it implements `std::marker::Tuple`.\n\nOk, I'm normally weakly against optional or named arguments. But this has actually won me over — it's a resolution to the perma-unstable magic in the `Fn` traits (currently spelled `extern \"rust-call\"`), making that functionality available in the surface language.\n\nI'm quite iffy on splatting a function generic into its signature, since type inference seems like it would be a pain. If the splatted trait is not sealed, can any crate add new \"overloads\" to the function? What types in the transitive dependency tree are eligible during overload selection? It feels like this portion would be better served by splatting a concrete type and defining what argument lists are valid by some `trait FromArgList<Args: Tuple>`, since that gives us useful orphan rules semantics and reuses exactly how we already know type inference to function.\n\nThe general idea of splatting tuples feels at home, and seems like it could fairly easily be extended to working for variadic generic use cases as well. But overloading doesn't, imo, and my instinct is telling me that splatting named fields is better served by type inferred struct literal syntax.",
  "title": "[Pre-pre-RFC] \"splatting\" for named arguments and function overloading"
}