[swift-evolution] [Review] SE-0042 Flattening the function type of unapplied method references

[Brent Royal-Gordon]

> 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)`.

-- 
Brent Royal-Gordon
Architechies