External Publication
Visit Post

[Pre-pre-RFC] "splatting" for named arguments and function overloading

Rust Internals [Unofficial] June 16, 2026
Source

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.

I 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:

fn foo<A, B>(a: A, b: B) -> (A, B)
where
  A: FirstTrait,
  B: SecondTrait,
{
  (a, b)
}

// ..is effectively sugar for..

struct foo;

impl<A, B> Fn<(A, B)> for foo
where
  A: FirstTrait,
  B: SecondTrait,
{
  type Output = (A, B);

  fn call(&self, ...(a, b): (A, B)) -> (A, B) { (a, b) }
}

This is basically how it works already internally, except that it uses the perma-unstable rust-call calling convention. This proposal brings it into userland.

The 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:

fn make_closure<A, B>(a: A, b: B) -> impl Fn() -> Foo {
  move || {
    // ...
  }
}

Since 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)).

Discussion in the ATmosphere

Loading comments...