[swift-evolution] Splat

[Brent Royal-Gordon]

So, since SE-0029 has been accepted, let's think about explicit replacements. So far, I've been able to think of three general approaches. For the examples below, I'll assume there's a `func concatenate(number: Int, to string: String) -> String`, which does the obvious thing. Where supported, I will fully qualify names with SE-0021 syntax, but in some cases this might not be necessary.

		1. Special parameter label.

`concatenate` is implicitly overloaded with a `func concatenate(parameters: (Int, String)) -> String`.

	concatenate(parameters: tuple)
	tuples.map(concatenate(parameters:))

Advantages: 
- Does not require any new call-side syntax.
- Googleable thanks to use of identifiers.

Disadvantages:
- Could conflict with functions that use `parameters` as an argument label.
- Not clear how it would distinguish between `concatenate(_:to:)` and e.g. `concatenate(_:with:)`.
- Might reintroduce type checking complexity, since it's adding overloads.
- A bit wordy.
- As far as I know, not precedented in other languages.

		2. Method on functions.

`concatenate` has a method on it called, say, `apply(to:)` which takes a tuple of parameters.

	concatenate(_:to:).apply(to: tuple)
	tuples.map(concatenate(_:to:).apply(to:))

Advantages:
- You can be sure of the variant you're selecting.
- Googleable thanks to use of identifiers.
- Similar to usage in Javascript.

Disadvantages:
- Rather wordy, with lots of chaining and extra parentheses.
- Methods on unapplied functions might be a little confusing.

		3. Splat operator.

An operator like `*` is used to indicate splatting. A tuple can be put to the right of the operator to splat it in immediately, or it can be omitted to select a splattable version of the function.

	concatenate(_:to: *tuple)
	tuples.map(concatenate(_:to: *))

Advantages:
- You can be sure of the variant you're selecting.
- Similar to usage in Ruby and Perl 6.
- Fairly short in all forms.

Disadvantages:
- Not Googleable.
- New magic syntax.
- Two slightly different forms depending on whether you're calling or not.

Any thoughts on these, or alternative approaches (as opposed to small syntax tweaks)?



P.S. As for pointers potentially using prefix `*` for memory dereferencing, I would instead make them use postfix `!`. `!` could become an `unwrapped` pseudo-property that any type can use, democratizing another piece of `Optional` magic and working around the vexing problem of what you name the `Pointer` property for "that thing you're actually pointing to".

-- 
Brent Royal-Gordon
Architechies