[swift-evolution] Changing the curried static methods

[Brandon Williams]

Ah, thanks for the reference. I wasn’t aware of that proposal.

I wish currying wasn’t going away, but aside from that I think there’s
still a strong case for flipping the arguments since it simply reads better
for the arguments to follow the name of the method.




On Mon, Mar 14, 2016 at 1:09 PM Joe Groff <jgroff at apple.com> wrote:

>
> On Mar 12, 2016, at 1:46 PM, Brandon Williams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Right now instance methods on a type get a curried, static method for
> free, e.g. CGRect.insetBy is a curried function CGRect -> (CGFloat,
> CGFloat) -> CGRect. This is super cool and great for code reusability.
>
> Unfortunately, I think the order of the curry makes it difficult to use
> most of the time. With the above example you would use it as such:
>
> CGRect.insetBy(rect)(10.0, 10.0)
>
> That doesn’t read very nicely, and it’s more likely that you know (10.0,
> 10.0) before you know rect, hence you would want to call it as:
>
> CGRect.insetBy(10.0, 10.0)(rect)
>
> In general, I would expect a method:
>
> struct A {
>   func method <B, C> (b: B) -> C
> }
>
> to have a static method of the form
>
> A.method: B -> A -> C
>
> Does this make sense? Is there a reason for the current design that I’m
> not seeing?
>
>
> Note that there's a proposal open to flatten away the currying altogether:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md
>
>
> I agree that it would often be more useful to bind the non-self arguments
> first. Maybe we could provide a different shorthand for that, though; a
> number of people for instance have suggested `.insetBy(10.0, 10.0)` as a
> possibility.
>
> -Joe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160314/23ad4a4a/attachment.html>