Tracking Issue for argument splatting lang experiment

[teor2345]

This is a tracking issue for the lang experiment into argument splatting, for function overloading and variadic functions (including leaving out optional arguments entirely).
The feature gate for the issue is #![feature(splat)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Experiment Goals

This experiment facilitates limited forms of function overloading, variadic functions, and optional arguments, by improving the existing syntax at the call site.

Rust already has "overloading at home" via the trait system, but calls to overloaded or variadic functions look strange. The goal of this experiment is to make the call sites look like ordinary function calls, and see how that impacts FFI, coherence, and ergonomics.

Eventually, overloading might improve the usability of many near-identical standard library methods.

Experiment Non-Goals

Rust already has "named arguments at home" via argument destructuring, but calls to named argument functions need to create a struct. We could make call sites look like regular function calls (but with argument names), but that is out of scope for the initial experiment.

Steps

• Land no-op feature gate and experimental syntax, for example, fn foo(#[splat] (T, U, …))
• Land Tuple-only splatting by tupling during typechecking
  • Experiment with using the Tuple trait for FFI overloads using Crubit or similar
  • Experiment with using the Tuple trait for variadic versions of stdlib functions like min() or zip()
  • Land tests for overloading
  • Land tests for variadics
  • Land tests for coherence edge cases
• Optimise by de-tupling at codegen time
  • Land codegen tests
• Start an RFC based on what's been learned

Unresolved Questions

• What limits does trait coherence put on foreign function overloads (or variadic functions)?
• Should splatted overloads be sealed, or can any crate add new overloads?
• Can we leave out optional arguments entirely using this feature, or is there a better way?
• What syntax should Rust use for splatting?

Ergonomics

• Will this encourage APIs with large numbers of arguments? How can (or should we) discourage that?
• How can we improve method resolution lookup failure diagnostics, so they aren't a large list of different generic tuple lengths?
• How does this impact code review, code navigation, and editor suggestions?

Sources:

• “splatting” for named arguments and function overloading
• Call an overloaded C++ function from Rust rustfoundation/interop-initiative#14
• Example code using existing unstable features
• #t-lang > On overloading @ 💬 - implementation strategy

Implementation history

• Add arg splat experiment initial tuple impl #153697