[swift-evolution] Splat

[Craig Cruden]

Do you need access to the same functions using tuple-splat and non-tuple splat way — or just need a way to generically pass parameters from a tuple (homogeneous list of typed values - label accessible as content type) of variable length?


> On 2016-02-11, at 4:21:32, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution