[swift-evolution] Spread Operator as Shorthand for Map

[Matthew Johnson]

> On Dec 17, 2015, at 6:47 AM, Stephen Celis <stephen.celis at gmail.com> wrote:
> 
>> On Dec 17, 2015, at 12:33 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>>>> If you remove that overload your code will fail to compile.  This is because the dot abbreviation is context sensitive.  It only works when the type system knows the type the expression is expected to produce.
>>> 
>>> Of course :) And if the overload stays and your suggested syntax were added, it would be ambiguous and also fail to compile.
>> 
>> This is not true.  They would have different types and therefore would not be ambiguous.
> 
> It's true in my example, but my example is an unlikely, type-ambiguous situation and is unlikely to occur in usage.

I finally managed to see the ambiguity in your example and now I feel foolish for not seeing it right away.  Thanks for sticking with it until I understood your example correctly.  :)  I think it’s because I just kept thinking of the usual signature of map and maybe also because I was thinking more in terms of grammatical ambiguity.

The overload in your example is possible but doesn’t really make any sense.  Nonetheless, it does show that a certain kind of ambiguity is possible.  

The good news is that this is a kind of ambiguity that already exists in the language today.  The compiler catches it and just requires you to resolve it manually when it arises.  The same would be true if we adopt the instance method shorthand.

struct Foo {
    static var ambiguous: Foo = Foo()
}

struct Bar {
    static var ambiguous: Bar = Bar()
}

func overloaded(foo: Foo) { }
func overloaded(bar: Bar) { }

overloaded(.ambiguous) // compile error

> 
>> But it’s not central to your position anyway since you are opposed on the grounds of potential for confusion rather than actual ambiguity.  :)  That is a fair and reasonable position with or without ambiguity.
> 
> I'm not opposed to the idea if it has broad applications and the type resolution is predictable. I think I'm probably doing a bad job of predicting.

Glad to hear you’re not completely opposed.  I think it would have pretty broad applicability.  It wouldn’t do anything you couldn’t achieve with a closure: { $0.method() }, but it would improve clarity and readability by removing syntactic noise.  

I’m going to start a new thread to bring more people into the discussion about this.

Matthew

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