<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Oh please, please, never let those leave TypeLift's repositories until HKTs get merged... :P</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I guess what I want is consistency, either of implementation or of terminology. Because right now the language has neither and is trampling a function with a very consistent, rigorous definition for what I'm not sure?<br><br>~Robert Widmann</div><div><br>2015/12/04 23:56、Harlan Haskins <<a href="mailto:harlan@harlanhaskins.com">harlan@harlanhaskins.com</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class=""></pre>Y’know, <font face="Menlo" class="">map</font> and <font face="Menlo" class="">flatMap </font>being part of <font face="Menlo" class="">SequenceType</font> is really a misnomer.<div class=""><br class=""></div><div class="">We could always just add <font face="Menlo" class="">Functor </font>and <font face="Menlo" class="">Monad</font> in the standard library!</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class="">protocol Functor {</font></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class=""> typealias A</font></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class=""> typealias B</font></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class=""> typealias FB</font></div><p style="margin: 0px; line-height: normal; min-height: 17px;" class=""><font face="Menlo" class=""> <br class="webkit-block-placeholder"></font></p><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class=""> func map(_: A -> B) -> FB</font></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class="">}</font></div><div style="margin: 0px; line-height: normal; min-height: 17px;" class=""><font face="Menlo" class=""><br class=""></font></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class="">protocol Monad: Functor {</font></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class=""> static func pure(f: A) -> Self</font></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class=""> func flatMap(f: A -> FB) -> FB</font></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class=""> func >>=(x: Self, f: A -> FB) -> FB</font></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class="">}</font></div><div style="margin: 0px; line-height: normal; min-height: 17px;" class=""><font face="Menlo" class=""><br class=""></font></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class="">infix operator >>= { associativity left }</font></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class="">func >>=<M: Monad>(x: M, f: M.A -> M.FB) -> M.FB {</font></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class=""> return x.</font><span style="font-family: Menlo;" class="">flatMap</span><span style="font-family: Menlo;" class="">(f)</span></div><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" class="">}</font></div><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" 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 the STL or the reasons given for the closing of both radars.
><i class=""> This issue behaves as intended based on the following:
</i>><i class="">
</i>><i 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 general, if you view Optional as a sequence of zero or one T. It resembles this overload, where the closure returns an arbitrary sequence:
</i>><i class="">
</i>><i class=""> extension SequenceType {
</i>><i class=""> public func flatMap<S : SequenceType>(transform: (Generator.Element) -> S) -> [S.Generator.Element]
</i>><i class=""> }
</i>><i class="">
</i>><i 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 a different name (and force users to learn it, and differentiate between the two), since conceptually the operation is the same.
</i>
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.
Possible changes include:
1) Remove or rename Optional’s flatMap.
This would cause a bit of breaking behavior, but it’s nothing some fixits couldn’t help with.
2) Add a SequenceType instance for Optional.
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.
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> <<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>>).</pre></blockquote><div class=""><br class=""></div></div></div></blockquote></body></html>