[swift-evolution] Splat

Jacob Bandes-Storch jtbandes at gmail.com
Wed Feb 10 15:52:06 CST 2016


Weird idea based on #1: since some folks were discussing having "$$" as a
special identifier meaning "all arguments" in a closure, perhaps the
special parameter label could be $$ as well?

    concatenate(mytuple.0, mytuple.1)
    concatenate($$: mytuple)

On Wed, Feb 10, 2016 at 1:21 PM, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160210/41d53b91/attachment.html>


More information about the swift-evolution mailing list