[swift-evolution] [Review] Add a Lazy flatMap for Sequences of Optionals

[Jordan Rose]

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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>  
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151219/606f4658/attachment.html>