[swift-evolution] [Idea] Syntactic sugar for using methods as functions

[Félix Cloutier]

Wow. I did not see that coming!

Either way, I agree that Foo.bar works, but then again, so does Enum.value and we give that one a free pass. Beyond "it's not how it works right now", I don't really have any serious argument against the feature. I'd like to have that at some point.

Félix

> Le 27 juin 2016 à 14:07:46, Anton Zhilin via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> Charlie Monroe via swift-evolution <swift-evolution at ...> writes:
> 
>> This will only get you an array of closures:
>> 
>> let bars = foos.map(Foo.getBar) // [() -> Int, () -> Int, () -> Int]
>> bars[0]   // () -> Int
>> bars[0]() // 1
> 
> Just checked:
> 
> struct A {
>    func a() -> Int { return 0 }
> }
> print(A.a.dynamicType)  //=> (A) -> (()) -> Int
> 
> Wut?
> 
> First of all, (()) -> Int should mean function with one parameter, since 
> tuple splat behaviour is going to be removed.
> 
> Then, with uncurrying proposal, A.a.dynamicType should be (A) -> Int, 
> because both self and other parameters are now passed together.
> 
> My guess is that both accepted proposals are still not implemented. Once 
> it's done, we will get (A.a)(A()) == 0 and [A(), A()].map(A.a) == [0, 0]
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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