[swift-evolution] [Review] SE-0042 Flattening the function type of unapplied method references
brent at architechies.com
Wed Mar 16 20:39:06 CDT 2016
> I'm in favor. Unbound methods have always existed in a sort of awful tension between being usable in higher-order algorithms and being usable in more down-to-earth situations like `map`. With the demise of curried functions and implicit tuple splatting, the higher-order stuff isn't really a factor anymore, and we should make this feature more usable for the simple stuff.
> One thing that's missing from this proposal is discussion of readability. For instance, this is serviceable but doesn't read well:
> Set.remove(&mySet, element)
> It might read a little better if the `self` parameter were given an appropriate argument label:
> Set.remove(from: &mySet, element) // `from` won't be appropriate for other verbs
> Set.remove(self: &mySet, element) // `self` is clear, but doesn't read naturally
> Set.remove(in: &mySet, element) // `in` should work okay for most methods
> Set.remove(element, in: &mySet) // `in` reads better at the end, but do we want it there?
> On the other hand, we might just be of the opinion that this is kind of a low-level feature and we don't really care how it reads.
Something I forgot to mention: if this proposal is accepted, we may want to extend leading-dot syntax to attempt to look up an unbound method on the type of whatever would be the `self` parameter. That would let you say things like `arrays.map(.max)`.
More information about the swift-evolution