[swift-evolution] Spread Operator as Shorthand for Map

[Matthew Johnson]

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

I believe the dot abbreviation only works for enum cases right now.  I suppose those can be viewed as static members in some sense but they really something different than that.  If I am mistaken I would like to be corrected.

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

Yes, they behave somewhat differently as they are an extension of the behavior to struct and class instance members.

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

The shadowing is *current* behavior in the language.  It is not something I propose.

> 
> 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`?

This would not refer to either.  It cannot refer to Foo.bar because Foo has nothing to do with the array you are mapping over.  The syntax matching my example would be:

[1, 2, 3].map(.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.

In the enum example here you cannot refer to .Bar in an arbitrary context.  It must be known by context that you are referring to a case of Foo.  It appears to me like your understanding of the existing dot abbreviation for enums is not quite correct and this misunderstanding is probably contributing to your misunderstanding and confusion regarding my examples.

Matthew

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