[swift-evolution] Changing the curried static methods

[Erica Sadun]

I'm probably missing the point here, so apologize in advance. Instead of reducing a function with an n-arity set of arguments to a partially applied function with (m|m<n)-arity set of arguments, it's building a functional application and applying that to an arbitrary receiver.

	`UIView.removeFromSuperview(receiver) `

defines

	`receiver.removeFromSuperview`

which can then be applied with whatever arguments, () in this case.

	`UIView.removeFromSuperview(receiver)()` aka `receiver.removeFromSuperview()`

With mapping, you can do:

let v = UIView()
(1...5).forEach{_ in v.addSubview(UIView())}

// You can apply each subview as a receiver, returning a function
let applied = v.subviews.map(UIView.removeFromSuperview) 
// [(Function), (Function), (Function), (Function), (Function)]

// And then you an execute them in forEach
print(v.subviews.count) // 5
v.subviews.map(UIView.removeFromSuperview).forEach{$0()}
print(v.subviews.count) // 0

The whole map/forEach could be defined down to apply in a possible language extension, as I mentioned before.

-- E, who apologizes for really not getting this


> On Mar 13, 2016, at 1:21 PM, Brandon Williams <mbw234 at gmail.com> wrote:
> 
> I think this highlights some of the confusion around the current curried convention. Void methods are curried as A -> () -> (), which means you would use it like:
> 
> UIView.removeFromSuperview # => UIView -> () -> ()
> UIView.removeFromSuperview(view) # => () -> ()
> UIView.removeFromSuperview(view)() #> ()
> 
> I find this confusing because removeFromSuperview reads as an action, yet UIView.removeFromSuperview(view) does not perform the action but rather is an action itself that requires a further invocation ().
> 
> With arguments flipped we would have:
> 
> UIView.removeFromSuperview # => () -> UIView -> ()
> UIView.removeFromSuperview() # => UIView -> ()
> UIView.removeFromSuperview()(view) #> ()
> 
> It now reads to me that UIView.removeFromSuperview() is the action that will do the removing, and UIView.removeFromSuperview()(view) is applying the action to a view.
> 
> I don’t advocate using removeFromSuperview in this manner, but if one were to I believe the latter convention is easier to reason about without having to look up types in a playground (as I had to do a few times to write this :P)
> 
> 
> On Sun, Mar 13, 2016 at 1:50 PM Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> > On Mar 13, 2016, at 11:30 AM, Stephen Celis <stephen.celis at gmail.com <mailto:stephen.celis at gmail.com>> wrote:
> >
> >> On Mar 13, 2016, at 1:18 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
> >>
> >> Since removeFromSuperview doesn't take a UIView argument, it sounds like what you're looking for is
> >> something that acts like "apply", to apply a lambda/closure/selector/whatever to each member of a collection.
> >>
> >> view.subviews.apply(UIView.removeFromSuperview)
> >>
> >> -- E
> >
> > This is what `forEach` currently does with the existing curried static syntax, right?
> >
> > I was more interested in the implications of an example brought up in the OP:
> >
> >    frames.map(CGRect.insetBy(-10, -10))
> >
> > - Stephen
> 
> forEach currently does f(x).
> apply would do x.f()
> 
> -- E
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

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