<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=""><div class="">After thinking about it for a bit, I'm against Optional conforming to CollectionType <i class="">specifically</i> because of those extra members on Optional. Quite a few of the operations on general SequenceTypes and CollectionTypes just don't make sense:</div><div class=""><br class=""></div><div class="">- elementsEqual/lexicographicalCompare</div><div class="">- dropFirst/Last</div><div class="">- joinWithSeparator<br class=""><div class=""><div class="">- min/maxElement</div><div class="">- reduce</div><div class="">- partition/sort</div><div class="">- split</div><div class="">- startsWith</div><div class=""><br class=""></div><div class="">It's not that CollectionOfZeroOrOne isn't sometimes useful; it's that users of Optional shouldn't be confronted with these useless APIs. Things like Array.init and Set.init that take sequences also feel weird to use with Optional.</div><div class=""><br class=""></div><div class="">This clicked with me after the discussion about Optional<Void> and Bool: just because two types are isomorphic (in the sense of having a bijection, i.e. value-preserving transformations in both directions) doesn't mean they're the same, or <i class="">should</i> be the same. This is similar to how implementing all the members of a protocol doesn't automatically mean you conform to the protocol; the protocol has semantic requirements too.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 0:16 , Kevin Ballard 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="">
<title class=""></title>
<div class=""><div class="">I've stated in the past that I'd like to see Optional conform to SequenceType. It may as well conform to CollectionType too. The only real drawback I'm aware of is the addition of extra methods/properties on Optional, which shouldn't actually be a problem, it just seems a little noisy.<br class=""></div>
<div class=""> </div>
<div class="">Incidentally, pre-1.0 Rust used to actually have a fair amount of code that used a for-loop to iterate an Option. The Option type still is iterable, but the introduction of `if let` into Rust served to replace the existing uses of the for loop.<br class=""></div>
<div class=""> </div>
<div class="">In any case, I'm broadly in favor of supporting lazy.flatMap. I'm concerned about the specific implementation in the proposal because LazyMapSequence<LazyFilterSequence<LazyMapSequence<Elements, T?>>, T> is kind of a ridiculous type to be getting back from a single call to flatMap(). I'm most in favor of making Optional conform to CollectionType and using that to simply flatMap; barring that, the CollectionOfZeroOrOne idea looks promising.<br class=""></div>
<div class=""> </div>
<div class="">-Kevin Ballard</div>
<div class=""> </div>
<div class="">On Wed, Dec 16, 2015, at 12:03 AM, Dave Abrahams via swift-evolution wrote:<br class=""></div>
<blockquote type="cite" class=""><div class=""> </div>
<div class=""><blockquote type="cite" class=""><div class="">On Dec 15, 2015, at 7:21 PM, Rob Mayoff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div>
</blockquote><blockquote type="cite" class="">Dmitri wrote:<br class=""></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;" class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""> </div>
<div class=""><span class="">What's the advantage? Why would we want to have a type that is isomorphic to Optional, except that conforms to CollectionType?</span><br class=""></div>
<div class=""> </div>
</div>
</div>
</div>
</blockquote><div class=""> </div>
<div class="">My question (apologies if it has been answered already) is: Why isn't Optional a CollectionType, like it is in Scala?<br class=""></div>
</div>
</div>
</div>
</div>
</blockquote></div>
<div class="">I don't remember the rationale, but it <a href="https://github.com/apple/swift/commit/fad874708e05cff56aec5587a4b0f49cdadc6d11" class="">used to be that way</a> and during the run-up to the Swift 1 release IIRC several members of the Swift team objected to it. That's the answer to Dmitri's question: I have considered that to be off the table, but we could revisit it. <br class=""></div>
<div class=""> </div>
<div class="">One cute effect, which might be too cute for some, is that<br class=""></div>
<div class=""> </div>
<div class=""> if let x = y { ... } <br class=""></div>
<div class=""> </div>
<div class="">becomes equivalent to<br class=""></div>
<div class=""> </div>
<div class=""> for x in y { ... }<br class=""></div>
<div class=""> </div>
<div class="">when y is an optional.<br class=""></div>
<div class=""><div class=""> </div>
<div class=""><div class="">-Dave<br class=""></div>
<div class=""> </div>
</div>
</div>
<div class=""><img style="height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-bottom:0px !important;margin-right:0px !important;margin-left:0px !important;padding-top:0px !important;padding-bottom:0px !important;padding-right:0px !important;padding-left:0px !important;" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/05a09c798ba1f6a65f2313b0871828d696ce3f951a36b5c43fbfd42ddd20ac93/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d3148765176786c673171614a7d2236454230345272776e435f453245565a7d2232475e485147513451736175316252603a717642587977745152337a423545547d4a464c6d4b66366d22364d48447850534e493c68373c684a67757673687035755a415a597234666741356256307a45675e6232325d22324d636e6a5968466c4c4a487c666854483163534f6d6e6456353934317a69643641795a566a735b6c6d2232444d416b6a713444516e643e6336363f465c4833455279767142327c633e427052417452547d415369596242316d2232456876577f425365396865646852776d23344d23344/open" class=""><br class=""></div>
<div class=""><u class="">_______________________________________________</u><br class=""></div>
<div class="">swift-evolution mailing list<br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</blockquote><div class=""> </div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ZEz4qHYnXhPr3bBPu-2FxP4tN3HfWKL-2FtJpqkQ0gkOVSDsT4Rtle3UcYZIuCR-2BppCDtbGXYyYTMzFYmWegSOYGwfVacT87A2HL4PEPzut-2F9ijeSLiwUk2K7Bcc95x0irP5Joi8wKQxOF4jSSljCITrRHXAvh6ATOvm0qjSgkQfyJkWZNswtaQa4agA5kJZMccbPQNJhq8My8re5a8NXM438B-2FQiUzlKl1TqBVDOX4mFj4-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>