[swift-evolution] Spread Operator as Shorthand for Map

[Matthew Johnson]

> 
> Sorry, I meant ambiguous via extension (on a sequence type). Super contrived example:
> 
>     struct Foo {
>         static var bar = Foo()
>     }
>     extension Array {
>         func map(foo: Foo) {}
>     }
>     [1, 2, 3].map(.bar)
> 
> I doubt there would be much ambiguity in practice, as disambiguation would come naturally at the call site.
> 
> There would not be an entirely new meaning for the . shorthand.  It would be an extrapolation of the shorthand for enum cases.
> 
> I merely meant that dot-abbreviation now specifically resolves to a static member that returns the type. The dot-abbreviation in your examples is a different behavior and adds a bit of complexity to learning Swift.

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)

Here are some examples:

struct Foo {
    var bar: Foo

    func bar() -> OtherType
    func bar(s: String) -> OtherType

    // the property shadows the static function when accessed with Foo.bar syntax
    // the same behavior would be exhibited in the shorthand if it applied to static members
    static func bar(f: Foo) -> OtherType {}
    static var bar: Foo -> OtherType = { _ in OtherType() }
}

[Foo]().map(.bar()) // instance method
[Foo]().map(.bar(“hello")) // instance method
[Foo]().map(.bar#get) // instance property

// this would reference a static property or static function if that is allowed
// however if we define the dot-abbreviation to access only unbound instance members
// this could be a shorthand for .bar#get as it would be the only unbound instance member with the correct type
[Foo]().map(.bar) 

// 
[Foo]().map(.bar) 

If we do add a dot-abbreviation like this it would probably make sense to define it such that it only applies to curried functions where the first argument is of the type required in the context.  Because curried syntax is getting dropped that would mean only unbound instance methods / properties / subscripts would be eligible.  Because the dot-abbreviation would be defined as an unbound reference we probably don’t need the special syntax for getters and subscripts.

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).

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.

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