<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=""><span class="">A few months ago I sent a pair of radars (22414579 nee 22448207 and 21961711) about Optional’s extant overloading of flatMap and how it doesn’t align with either&nbsp;the STL or the reasons given for the closing of both radars.&nbsp;&nbsp;</span><div class=""><span class=""><br class=""></span></div><span class=""></span><blockquote type="cite" class=""><span class="">This issue behaves as intended based on the following:<br class=""><br class="">Yes, we are aware that this overload of flatMap could be viewed as unconventional. Nevertheless, it is useful and fits the overload set in&nbsp;general, if you view Optional as a sequence of zero or one T. It resembles this overload, where the closure returns an arbitrary sequence:<br class=""><br class=""></span><div class=""><span class="">extension&nbsp;SequenceType&nbsp;</span>{<span class=""><div class="">&nbsp; public&nbsp;func&nbsp;flatMap&lt;S&nbsp;:&nbsp;SequenceType&gt;(transform: (Generator.Element)&nbsp;-&gt; S)&nbsp;-&gt;&nbsp;[S.Generator.Element]</div></span><span class=""><div class="">}</div><br class="">The type checker ensures that there is no ambiguity between the two overloads, and we don't see a reason to give one of the overloads&nbsp;a different name (and force users to learn it, and differentiate between the two), since conceptually the operation is the same.<br class=""></span></div></blockquote><div class=""><span class=""><br class=""></span><div class=""><span class="">If Swift wishes to regard Optionals as collections with 1 or 0 elements, then I propose that it should reflect that thinking with additions to the standard library.</span><div class=""><span class=""><br class=""></span></div><div class=""><span class="">Possible changes include:</span></div><div class=""><span class=""><br class=""></span></div><div class=""><span class="">1) Remove or rename Optional’s flatMap. &nbsp;</span></div><div class=""><span class="">This would cause a bit of breaking behavior, but it’s nothing some fixits couldn’t help with.</span></div><div class=""><span class=""><br class=""></span></div><div class=""><span class="">2) Add a SequenceType instance for Optional.</span></div><div class="">This kills 2 birds with 1 stone in that, if the radar rejection is to ring true, Optional should have a SequenceType instance in the STL, and such an instance would automatically come with its own proper overloading flatMap necessitating change 1.</div><div class=""><br class=""></div><div class="">&nbsp;Over in TypeLift land we’ve already implemented what we believe the SequenceType extensions should look like (<a href="https://github.com/typelift/Swiftz/blob/master/Swiftz/OptionalExt.swift#L139-L145" class="">https://github.com/typelift/Swiftz/blob/master/Swiftz/OptionalExt.swift#L139-L145</a>).</div></div></div></body></html>