<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>Am 21.03.2016 um 04:36 schrieb Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">* Are the current stdlib names for optional <font face="Courier" class="">map</font> and <font face="Courier" class="">flatMap</font> misleading? </div></div></blockquote></div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">It depends on the interpretation. The one that I came across in “Functional Swift” describes map and flatMap for container types that are not necessarily collections (Result is another container type that immediately comes to mind which is not a collection). Since these concepts are not specific to Swift, I think that it’s very important that Swift uses the names that are already established for these concepts.<br class=""></div></div></div></div></blockquote><div><br></div>+1<div>Functional concepts are a powerful thing and it would be a mistake for Swift to shy away from them or try to hide concepts like functors or monads in the async corner like Java or C# do. More and more languages embrace these concepts. Mind that I don't say that Swift should go the same road as Haskell, I think we can do many things better.</div><div><br><blockquote type="cite"><div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">* Are the current stdlib functions for optional closure application appropriate and sufficient?</div></div></blockquote><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">I’d love to see what is called “ifPresent” in the subject of the thread. But I think that it should be called “apply” (<a href="https://en.wikipedia.org/wiki/Apply" class="">https://en.wikipedia.org/wiki/Apply</a>)</div></div></div></div></div></div></div></blockquote><div><br></div>Apply is just function application without extracting the argument from its context first (or taking it out of its container if you prefer that analogy). So it would be the wrong name.</div><div><br></div><div>-Thorsten </div><div><br></div><div><br><blockquote type="cite"><div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 20, 2016, at 1:52 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Questions being raised in this discussion:</div><div class=""><br class=""></div><div class="">* Are the current stdlib names for optional <font face="Courier" class="">map</font> and <font face="Courier" class="">flatMap</font> misleading? </div><div class="">* Are the current stdlib functions for optional closure application appropriate and sufficient?</div><div class=""><br class=""></div><div class=""><div class=""><font face="Courier" class=""> @warn_unused_result</font></div><div class=""><font face="Courier" class=""> public func map<U>(@noescape f: (Wrapped) throws -> U) rethrows -> U?</font></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><font face="Courier" class=""> @warn_unused_result</font></div><div class=""><font face="Courier" class=""> public func flatMap<U>(@noescape f: (Wrapped) throws -> U?) rethrows -> U?</font></div></div><div class=""><br class=""></div><div class="">Assume there could be up to three stdlib functions just for applying closures to .some-case </div><div class="">optionals. Would they look like this?</div><div class=""><br class=""></div><div class=""><font face="Courier" class="">public func f1<U>(@noescape f: (Wrapped) throws -> U) rethrows -> U?</font></div><div class=""><div class=""><font face="Courier" class="">public func f2<U>(@noescape f: (Wrapped) throws -> U!) rethrows -> U!</font></div></div><div class=""><div class=""><font face="Courier" class="">public func f3<U>(@noescape f: (Wrapped) throws -> U) rethrows -> Void</font></div></div><div class=""><br class=""></div><div class="">Right now f2/flatMap returns U?, not U or U!, and won't throw if nil, right? Should it</div><div class="">stay that way or change to something that throws and returns a guaranteed value?</div><div class="">Or maybe the current "f2" model (flatMap) be discarded and replaced by an </div><div class="">"<font face="Courier" class="">ifPresent</font>"-like Void call?</div><div class=""><br class=""></div><div class="">And regardless of which functions are included, what would the appropriate </div><div class="">names for each function style be?</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 20, 2016, at 11:22 AM, Andrey Tarantsov <<a href="mailto:andrey@tarantsov.com" class="">andrey@tarantsov.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">No. My argument is that map on collections and on optionals are two<br class="">completely different things. They unify on a level that does not<br class="">exist in Swift (higher-kinded types).<br class=""></blockquote><br class="">+1000.<br class=""><br class="">Optional.map is already highly unfortunate. It makes optional arrays especially painful to deal with, but even in general, you can no longer glance at the code and see which parts are dealing with many items and which parts are dealing with single items.<br class=""><br class="">I would definitely support renaming Optional.{map,flatMap}.<br class=""><br class="">A.<br class=""><br class=""></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>