{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib5cirhw6ptwddmyg3ry6gaevnqo6qqlogpiw3ggmr6uyhls3yidy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mogn7y57up62"
  },
  "path": "/t/pre-pre-rfc-splatting-for-named-arguments-and-function-overloading/24012?page=3#post_43",
  "publishedAt": "2026-06-16T14:37:43.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "type alias impl Trait"
  ],
  "textContent": "I think that the named argument aspect of this proposal is unnecessary, it would be a nice feature, in theory, but it's orthogonal. If Rust is going to support explicitly-named arguments, that should be a separate proposal, it should be implemented statically first, and then splatting should be considered as an extension.\n\nI feel pretty positive about tuple splatting, though, so long as it's only for built-in tuples (i.e., not for tuple structs). Then you could imagine something like the following:\n\n\n    fn foo<A, B>(a: A, b: B) -> (A, B)\n    where\n      A: FirstTrait,\n      B: SecondTrait,\n    {\n      (a, b)\n    }\n\n    // ..is effectively sugar for..\n\n    struct foo;\n\n    impl<A, B> Fn<(A, B)> for foo\n    where\n      A: FirstTrait,\n      B: SecondTrait,\n    {\n      type Output = (A, B);\n\n      fn call(&self, ...(a, b): (A, B)) -> (A, B) { (a, b) }\n    }\n\n\nThis is basically how it works already internally, except that it uses the perma-unstable `rust-call` calling convention. This proposal brings it into userland.\n\nThe usecase of this, for me, isn't so much about function overloading for e.g. `Iterator::zip` (although that would be nice, of course). It's more about reducing the use of the following pattern:\n\n\n    fn make_closure<A, B>(a: A, b: B) -> impl Fn() -> Foo {\n      move || {\n        // ...\n      }\n    }\n\n\nSince I could just use a single, nameable type. It would also be an escape hatch for one of the two most common uses of type alias impl Trait, i.e. the `Fn` traits. `Iterator` (the other of the two) already has an escape hatch, since you can easily implement a custom adapter even if it'll usually be less-efficient than using `std` adapters. `Fn` doesn't have anything like that. Tuple splatting isn't a feature without bikeshedding, but considering how much of a can of worms `type_alias_impl_trait` turned out to be, I could imagine a world where tuple splatting still ends up going from pre-pre-RFC to stable before `type_alias_impl_trait` does. At the end of the day, it's not much more than sugar for removing the extra pair of parentheses in `foo((a, b))`.",
  "title": "[Pre-pre-RFC] \"splatting\" for named arguments and function overloading"
}