> On 19 Dec 2015, at 22:03, Radosław Pietruszewski via swift-evolution
> <swift-evolution@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
