> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
