[swift-evolution] [Proposal Idea] dot shorthand for instance members

[Al Skipp]

> On 19 Dec 2015, at 22:03, Radosław Pietruszewski via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> That is a fair position.  It sounds like you oppose this shorthand for methods that require arguments but not for nullary methods and not for property getters.  Is that correct?  Do you believe it is valuable in those cases?
> 
> Correct. I’m for foo(.aMethod) and foo(.aProperty), but not foo(.aMethod(withArgs)), because the former maps pretty nicely to what we already have, and the latter can be seriously confusing.
> 
> PS. I’d like to try and analyze my Swift codebases to see how I usually use closures with things like map, just to have some (admittedly biased) data on what kind of patterns are common in practice.
> 
> — Radek


Methods that take arguments do introduce some interesting problems. Here is an example with current Swift syntax:
["dog","cat","rat"].map { $0.hasPrefix("ca") } // [false, true, false]

Now if we wanted to use the following syntax instead:
["dog","cat","rat"].map(.hasPrefix("ca"))

This would require auto-currying of the function, so that the parameter passed to ‘hasPrefix’ is partially applied. The ‘map’ function would then pass each element of the Array to the partially applied function. Further more the order of the parameters would need to be reversed to get the expected result. Basically it would need to do something like the following:

func hasPrefix(prefix: String)(str: String) -> Bool {
  return str.hasPrefix(prefix)
}

["dog","cat","rat"].map(hasPrefix("ca")) // [false, true, false]

Perhaps that’s too much implicit rearranging? I would find it odd if were necessary to use the current syntax for methods with arguments, but have the ability to use the shorter syntax for methods without args.

Al
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151219/5db1fae3/attachment.html>