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, using a macro
  • Experiment with using the Tuple trait for variadic versions of stdlib functions like min() or zip()
  • Land cross-crate caller/callee tests
  • Land tests that codegen is correct
  • 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

Semantics

• What limits does trait coherence put on foreign function overloads (or variadic functions)?
  • If two overloads overlap, and are prevented by Rust's trait coherence, (how can we|can we at all|should we) make it possible to call those overloads?
• Can we overload on the self type? (self, &self, &mut self, self: Pin<&mut Self›, self: CRef<Self>)

Syntax & Implementation Rules

• 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?
• Should splatting be allowed on closures, unboxed closures, or "rust-call" functions? What are the semantics?
• Which other ABIs should splatting be allowed on? "rust", "C", Windows C++ ABIs (cdecl, fastcall, thiscall, vectorcall), anything else?

Ergonomics & Diagnostics

• 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?

Future Work

• Will this eventually be useful as a replacement for the "rust-call" pseudo-ABI and related compiler features?
• If we allow overloaded functions with the same name in the same module, how will we disambiguate their symbols? (Currently, function definition symbols are just their paths, but overloaded functions have the sane name.)

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

Related features

• with Tracking issue for core::marker::Tuple #157987 can be used for overloading
• might replace Tracking issue for Fn traits (unboxed_closures & fn_traits feature) #29625 eventually

Implementation history

• Refactor FnDecl and FnSig non-type fields into a new wrapper type #155223 (refactor that isn't specific to this experiment)
• Arg splat experiment - syntax impl #157605
• Arg splat experiment - hir FnDecl impl #157699 and perf regression fixes:
  • perf: Use 1 bit to track splatting in FnDecl #155852
  • perf: Store 1 bit for splatting in FnDeclFlags #157954
  • perf: Inline some hot functions in FnDecl #157955
• Arg splat experiment - HIR FnSig impl #157811
• Add arg splat experiment initial tuple impl #153697
  • includes Fix ICE in label_fn_like for splatted args and add UI tests #157434
  • same as perf: store splat arg index in a single byte #158251
• Add extra splat tests #158677
• Fix splat ICEs and ban it in closures #158645

Experiments

TODO