> On Dec 19, 2015, at 5:29 PM, Al Skipp <[email protected]> wrote: > >> On 19 Dec 2015, at 22:03, Radosław Pietruszewski via swift-evolution >> <[email protected] <mailto:[email protected]>> 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. >
The shorthand syntax could be implemented in different was. If it is just shorthand for a single expression closure then rearranging the call like that isn’t necessary. In reality, from a user point of view it doesn’t matter how it is implemented and it might be best to think of it as a single expression closure regardless of how the implementation is done.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
