<div dir="ltr">Sorry for the confusion, I’m not looking for help to model something in particular. These are examples to show the difference between the current curried static convention and the one I think is more expressive.<div><br></div><div>To iterate, right now CGRect.insetBy(rect)(insets) just reads incorrectly to me. Considering that Swift aims to be expressive through method names and argument labels, I would expect this to be CGRect.insetBy(insets)(rect).</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Mar 13, 2016 at 10:54 PM Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> If static methods had their arguments flipped, we'd be able to easily construct functions like `CGRect.insetBy(10.0, 10.0)` and `CGRect.offsetBy(-20.0, 10.0)`. These are now free functions without any mention to a specific rectangle. We could compose them to get a function that simulataneously insets and translates, all without mentioning a rectangle. With today's static methods we'd have to apply `flip` to each one, i.e. `flip(CGRect.insetBy)(10.0, 10.0)`.<br>
><br>
> This becomes very powerful with constructing data pipelines that describe how to transform data without ever actually mentioning the data. There are quite a few examples of things like this in Cocoa. A nice one is Core Image, in which you can build a pipeline of filters that you can feed images into.<br>
><br>
<br>
By your description, it sort of sounds like you could want to create a method cascade:<br>
<br>
myRect<br>
..insetBy(args)<br>
..offsetBy(args)<br>
<br>
In this, the instance passes through each of the function calls, joining them into a fluent declaration<br>
with an implicit receiver.<br>
<br>
But it also sounds like you want to use functional chaining. Core Image can chain because it always has<br>
inputImage and outputImage and set defaults:<br>
<br>
myRect = myRect.insetBy(args).offsetBy(args)<br>
<br>
Alternative, you could be doing some kind of weird chaining thing where so long as the output and inputs match<br>
up they can be composed together:<br>
<br>
f = (x: insetByAble).insetBy(args)->(T:offsetByAble).offsetBy(args)->U<br>
myRect = f(myRect)<br>
<br>
But in the end, it kind of almost really sounds like you just want to write a function<br>
<br>
f(x: CGRect) -> CGRect {<br>
x.insetBy(10.0, 10.0)<br>
x.offsetBy(-20.0, 10.0)<br>
return x<br>
}<br>
<br>
Which of these are you aiming for?<br>
<br>
-- E<br>
<br>
</blockquote></div></div>