I don't have anything against it, besides that it is an additive feature and should probably wait for after Swift 3.
Félix > Le 27 juin 2016 à 07:22:42, David Rönnqvist via swift-evolution > <[email protected]> a écrit : > > +1. This makes sense to me. > > Since the API Guidelines say: “Prefer methods and properties to free > functions”, it would make sense to add sugar like this to make methods just > as convenient and clear to pass to higher order functions as free functions > currently are. > > I’m also wondering if the same syntactic sugar could work for property > getters. > > - David > >> On 27 Jun 2016, at 12:00, Manuel Krebber via swift-evolution >> <[email protected]> wrote: >> >> Hi everyone, >> >> I was thinking it would be nice to have a similar short notation for >> using methods in a functional way as there is for enum cases (and as >> I've been told static members in general). >> Let me give a rather contrived example: >> >> struct Foo { >> let bar: Int >> >> func getBar() -> Int { >> return self.bar >> } >> >> } >> >> let foos = [Foo(bar: 1), Foo(bar: 2), Foo(bar: 3)] >> let bars = foos.map{ $0.getBar() } >> >> What I am suggesting is to add syntactic sugar to bridge the gap between >> functional and object oriented programming. So instead you could write >> the following: >> >> let bars = foos.map(.getBar) >> >> While for parameterless functions this might not seem like much of an >> improvement, I think it helps when there are parameters involved: >> >> struct Foo { >> let bar: Int >> >> func combine(other: Foo) -> Foo { >> return Foo(bar: other.bar + self.bar) >> } >> } >> >> let foos = [Foo(bar: 5), Foo(bar: 6), Foo(bar: 1)] >> let reduced = foos.reduce(Foo(bar: 0)) { $0.combine(other: $1) } >> >> Which could become: >> >> let reduced = foos.reduce(Foo(bar: 0), .combine) >> >> This would also enable easier usage of custom operators for partial >> functions etc. on these methods. >> >> Basically whenever there is a parameter type (T, ...) -> U somewhere, >> one could write the prefix dot shortcut and the compiler would look for >> a method in type T with a signature (...) -> U and wrap the call to the >> method in a closure. In case that no such method can be found or it >> cannot be uniquely determined, it will result in a compile time error. >> >> This is just an idea though. Do you think this would be useful? I could >> see it help libraries like the Dollar library. It could then be used in >> both functional and object oriented ways, since most functions could >> become methods while maintaining a short syntax. >> >> >> Kind regards, Manuel >> >> >> >> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
