[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