> • What is your evaluation of the proposal?
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.
> • Is the problem being addressed significant enough to warrant a change
> to Swift?
Yes. Other changes in the language have rendered the old design a poor fit for
most purposes; this proposal restores its usability.
> • Does this proposal fit well with the feel and direction of Swift?
Yes.
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
The closest equivalents I've used are Ruby's UnboundMethod and Cocoa's
NSInvocation, but these are OO designs with vastly different designs.
> • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
I did a quick reading for the review, and I've also contributed to various
related discussions and reviews.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
