After thinking about it for a bit, I'm against Optional conforming to CollectionType specifically because of those extra members on Optional. Quite a few of the operations on general SequenceTypes and CollectionTypes just don't make sense:
- elementsEqual/lexicographicalCompare - dropFirst/Last - joinWithSeparator - min/maxElement - reduce - partition/sort - split - startsWith 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. 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 should 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. Jordan > On Dec 17, 2015, at 0:16 , Kevin Ballard via swift-evolution > <[email protected]> wrote: > > 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. > > 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. > > 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. > > -Kevin Ballard > > On Wed, Dec 16, 2015, at 12:03 AM, Dave Abrahams via swift-evolution wrote: >> >>> On Dec 15, 2015, at 7:21 PM, Rob Mayoff via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> Dmitri wrote: >>> >>> What's the advantage? Why would we want to have a type that is isomorphic >>> to Optional, except that conforms to CollectionType? >>> >>> >>> My question (apologies if it has been answered already) is: Why isn't >>> Optional a CollectionType, like it is in Scala? >> >> I don't remember the rationale, but it used to be that way >> <https://github.com/apple/swift/commit/fad874708e05cff56aec5587a4b0f49cdadc6d11> >> 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. >> >> One cute effect, which might be too cute for some, is that >> >> if let x = y { ... } >> >> becomes equivalent to >> >> for x in y { ... } >> >> when y is an optional. >> >> -Dave >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
