[swift-evolution] Spread Operator as Shorthand for Map

Stephen Celis stephen.celis at gmail.com
Wed Dec 16 12:50:52 CST 2015

On Wed, Dec 16, 2015 at 1:13 PM, Matthew Johnson <matthew at anandabits.com>

This is still not correct for a couple of reasons.  The meaning of the
> dot-abbreviation could be defined in several ways.  A static member
> returning the type is not one of them.  In the context of the current map
> example the type returned by the dot-abbreviation expression would be
> ‘Element -> OtherType’.  (Element being the type contained in the array,
> which would be Self in the context of that type)

I'm confused. Isn't a static member returning the type the _only_ way dot
abbreviation works right right now? Please correct me with an example if
I'm wrong.

Here are some examples:

I think I understand your examples. They just don't work right now and
behave differently than dot abbreviation currently works.

> It is possible this syntax would be *confusing* for some developers, at
> least until they learn how it works.  But I don’t think we’ve seen any
> examples of ambiguity yet (of course there may be some we just haven’t
> discussed yet).

The shadowing you propose in your example attempts to resolve the ambiguity
I was referring to.

Let's take my earlier example. It would theoretically produce ambiguity if
`Int` had a `bar` method. The resolver wouldn't have enough type
information to resolve things. E.g.:

    struct Foo {
        static var bar = Foo()
    extension Array {
        func map(foo: Foo) {}
    extension Int {
        func bar() -> String { return String(self) }
    [1, 2, 3].map(.bar) // would this refer to `Foo.bar` or `Int.bar`?

Your example would seem to prefer `Int.bar`. This kind of
complexity/gotcha/learning moment is something I'd rather avoid.

There is precedent for dot-abrreviation in the language already related to
> enums and this definitely improves clarity and readability.  I think it
> definitely deserves further consideration.

Enum cases are static members (e.g., `enum Foo { case Bar }` allows you to
reference the `Bar` case as `Foo.Bar`, or abbreviated as `.Bar` where type
`Foo` is expected). This is what I was trying to communicate before. (The
same static resolution lets you pass `.redColor()` where a `UIColor` is
expected.) I'm just not sure co-opting dot abbreviation to also work with
instance methods is worth the added complexity.

Hope I'm being clearer this time around, and let me know if I'm still not
making sense or if I'm missing anything.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/e5b0e4af/attachment.html>

More information about the swift-evolution mailing list