<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 23, 2016, at 3:36 PM, Andrey Tarantsov 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=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></blockquote><div class=""><br class=""></div><div class="">Not so much misleading, as being unfortunate when optionals and collections end up as neighbors in the code.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">* Are the current stdlib functions for optional closure application appropriate and sufficient?</div><div class=""><br class=""></div><div class=""><div class=""><span style="font-family: Courier;" class="">public func f1<U>(@noescape f: (Wrapped) throws -> U) rethrows -> U?</span></div></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></blockquote><div class=""><br class=""></div><div class="">I don't see why flatMap needs to be separate from map. It just does not make sense. I would only have</div><div class=""><br class=""></div><div class="">public func f2<U>(@noescape f: (Wrapped) throws -> U?) rethrows -> U?</div><div class=""><br class=""></div><div class="">and would call it "ifPresent", "then", "unwrap", "transform" or something like that.</div></div></div></div></blockquote><div><br class=""></div>Optionals of Optionals are valid, and it would be ambiguous which would be returned from a map overloaded to allow both optional and non-optional transform functions. So, map always assumes the transform returns a non-optional, and if it returns an optional value (and that was not what you wanted) you have to flatten. Hence flatMap to combine the two steps.</div><div><br class=""></div><div>-DW</div></body></html>