<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Great discussion!</div> <div id="bloop_sign_1458496496799185152" class="bloop_sign"><br></div> <div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div></div><div><div class="">Questions being raised in this discussion:</div><div class=""><br class=""></div><div class="">* Are the current stdlib names for optional<span class="Apple-converted-space"> </span><font face="Courier" class="">map</font><span class="Apple-converted-space"> </span>and<span class="Apple-converted-space"> </span><font face="Courier" class="">flatMap</font><span class="Apple-converted-space"> </span>misleading? </div></div></div></span></blockquote></div><p>I believe they could be. </p><p>From what I could read, the core team and a majority of community doesn’t believe that including the abstractions like Functor or Monad into the stdlib is a good idea. Which is ok - we have a number of great 3rd party implementations avaliable, e.g. Swiftz. Scala took the same route.</p><p>If we’re not trying to go into Haskell land, than keeping names like map and flatMap for Optional is just making it harder for the developers who are not familiar with the functional programming jargon. At the same time, those accustomed to functional programming will grab the concept very easily regardless of what it’s called. The name already vary significantly in various languages (see <a href="https://en.wikipedia.org/wiki/Map_(higher-order_function)#Language_comparison">https://en.wikipedia.org/wiki/Map_(higher-order_function)#Language_comparison</a> ).</p><p><br></p><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div class="">* Are the current stdlib functions for optional closure application appropriate and sufficient?</div></div></div></span></blockquote></div><p>I think not. Again, if we’re not pushing people into “don’t leave the monad” mindset than it’s a very good idea to provide a standalone method for side effects. Erica wrote the signature:</p><div><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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><p><br></p><p>However, I’m not sure about this one:</p></div></div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><span style="font-family: Courier;">public func f2<U>(@noescape f: (Wrapped) throws -> U!) rethrows -> U!</span></div></div></span></blockquote></div><p>I haven’t used implicitly unwrapped optionals at all, I just never found a good case for them. Why do you think this variant might be useful?</p><div><p><br></p><p>- Krzysztof</p><p><br></p><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">-- E</div><div class=""><br class=""></div><div class=""><div><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>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></span></blockquote></div></div></div></body></html>