[swift-evolution] Splat

Radosław Pietruszewski radexpl at gmail.com
Wed Feb 10 16:19:54 CST 2016


There was a discussion about using `…` as an _array splat_ operator, i.e:

    func foo(xs: Int…)
    let xs = [1, 2, 3]
    foo(xs…)

That would be symmetric with “…” defining a variable length argument, and also the same approach as Ruby, but instead of `*xs` which looks like memory dereferencing, `xs…`, which IMHO works better as a symbol for this.

Perhaps it would be possible to overload this operator to perform _tuple splat_ as well. (I haven’t put it through tough thorough thought, though.)

— Radek

> On 10 Feb 2016, at 22:21, 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



More information about the swift-evolution mailing list