[swift-evolution] Spread Operator as Shorthand for Map

[Stephen Celis]

On Wed, Dec 16, 2015 at 11:34 AM, Matthew Johnson <matthew at anandabits.com>
wrote:

> This wouldn’t be ambiguous with static methods.  Confusing to some
> developers possibly, but not ambiguous.  Map would be expecting a function
> that takes an instance.  Depending on the details of how it was defined in
> the language it could be ambiguous with a static property of a function
> type:
>

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.

Stephen

On Wed, Dec 16, 2015 at 11:34 AM, Matthew Johnson <matthew at anandabits.com>
wrote:

> This wouldn’t be ambiguous with static methods.  Confusing to some
> developers possibly, but not ambiguous.  Map would be expecting a function
> that takes an instance.  Depending on the details of how it was defined in
> the language it could be ambiguous with a static property of a function
> type:
>
> Car {
>   static let make: Car -> SomeOtherType
> }
>
> This potential ambiguity could probably be defined away by making the
> shorthand specifically apply to instance methods or something like that.
>
> There would not be an entirely new meaning for the . shorthand.  It would
> be an extrapolation of the shorthand for enum cases.
>
> That said, I was replying quickly and my example was not quite accurate.
>  “make" is a getter which cannot be accessed in unbound form today.  There
> are proposals to allow this to be done in other threads.  Syntax from one
> example is Car.make#get (lets not get caught up on syntax of that here).
> So correcting my example it would look like:
>
> cars.map(.make#get)
>
> If make was a method we would need to bind all of the arguments except the
> curried instance argument so it would look like this:
>
> cars.map(.make())
>
> And a method with more arguments would look like this:
>
> cars.map(.methodWithInt(1, string: “hello"))
>
> I’m not necessarily advocating for something like this, just trying to
> think through the implications of it at this point.
>
> Matthew
>
> On Dec 16, 2015, at 10:18 AM, Stephen Celis <stephen.celis at gmail.com>
> wrote:
>
> On Wed, Dec 16, 2015 at 10:50 AM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> If we peel off just the contextual shorthand aspect of this proposal you
>> could write:
>>
>> cars.map(.make)
>>
>> That does seem like a big win if it is feasible (doesn’t introduce
>> ambiguity or cause other significant challenges in implementation).
>>
>
> The above creates ambiguity if there were a `map` function that takes a
> type with a static member `make`.
>
> Alternatively:
>
>     cars.map{.make}
>
> Both create an additional meaning for dot abbreviation, though, which is
> confusing. I think I'm "-1" on this proposal as is. The existing form is
> clearer and relatively short as is.
>
> Stephen
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/418d41e3/attachment.html>