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


(Chris Lattner) #1

Hello Swift community,

The review of “Flattening the function type of unapplied method references” begins now and runs through March 21, 2016. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at:

Thank you,

-Chris
Review Manager


(Brent Royal-Gordon) #2

  • 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


(Patrick Gili) #3

  • What is your evaluation of the proposal?

This is consistent with removing curried functions from Swift, and hence I'm in favor of it; consistency is good.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

  • 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?

Well, it feels like many modern languages are going the opposite direction; that is, incorporating more functional programming. I think Swift's approach is more programmatic though.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read thoroughly.

···

(Matthew Johnson) #4

  • What is your evaluation of the proposal?

+1. This is a great proposal, especially for the functional use cases mentioned in the motivation section.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes. It makes functional use cases more clunky than necessary.

  • Does this proposal fit well with the feel and direction of Swift?

Very much so.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I followed the initial discussion on the list and have been looking forward to this proposal.

···

More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brent Royal-Gordon) #5

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