<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I don't have anything against it, besides that it is an additive feature and should probably wait for after Swift 3.<br class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 27 juin 2016 à 07:22:42, David Rönnqvist via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">+1. This makes sense to me. <br class=""><br class="">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.<br class=""><br class="">I’m also wondering if the same syntactic sugar could work for property getters.<br class=""><br class="">- David<br class=""><br class=""><blockquote type="cite" class="">On 27 Jun 2016, at 12:00, Manuel Krebber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Hi everyone,<br class=""><br class="">I was thinking it would be nice to have a similar short notation for<br class="">using methods in a functional way as there is for enum cases (and as<br class="">I've been told static members in general).<br class="">Let me give a rather contrived example:<br class=""><br class="">struct Foo {<br class=""> let bar: Int<br class=""><br class=""> func getBar() -> Int {<br class=""> return self.bar<br class=""> }<br class=""><br class="">}<br class=""><br class="">let foos = [Foo(bar: 1), Foo(bar: 2), Foo(bar: 3)]<br class="">let bars = foos.map{ $0.getBar() }<br class=""><br class="">What I am suggesting is to add syntactic sugar to bridge the gap between<br class="">functional and object oriented programming. So instead you could write<br class="">the following:<br class=""><br class="">let bars = foos.map(.getBar)<br class=""><br class="">While for parameterless functions this might not seem like much of an<br class="">improvement, I think it helps when there are parameters involved:<br class=""><br class="">struct Foo {<br class=""> let bar: Int<br class=""><br class=""> func combine(other: Foo) -> Foo {<br class=""> return Foo(bar: other.bar + self.bar)<br class=""> }<br class="">}<br class=""><br class="">let foos = [Foo(bar: 5), Foo(bar: 6), Foo(bar: 1)]<br class="">let reduced = foos.reduce(Foo(bar: 0)) { $0.combine(other: $1) }<br class=""><br class="">Which could become:<br class=""><br class="">let reduced = foos.reduce(Foo(bar: 0), .combine)<br class=""><br class="">This would also enable easier usage of custom operators for partial<br class="">functions etc. on these methods.<br class=""><br class="">Basically whenever there is a parameter type (T, ...) -> U somewhere,<br class="">one could write the prefix dot shortcut and the compiler would look for<br class="">a method in type T with a signature (...) -> U and wrap the call to the<br class="">method in a closure. In case that no such method can be found or it<br class="">cannot be uniquely determined, it will result in a compile time error.<br class=""><br class="">This is just an idea though. Do you think this would be useful? I could<br class="">see it help libraries like the Dollar library. It could then be used in<br class="">both functional and object oriented ways, since most functions could<br class="">become methods while maintaining a short syntax.<br class=""><br class=""><br class="">Kind regards, Manuel<br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>