[swift-evolution] [Pitch] Remove destructive consumption from Sequence

[Matthew Johnson]

Sent from my iPad

> On Jul 5, 2016, at 3:32 PM, David Waite <david at alkaline-solutions.com> wrote:
> 
> 
>>> On Jul 1, 2016, at 9:59 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> On Jun 30, 2016, at 12:26 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>>> 
>>> Q: Why not allow endIndex to have a different type from startIndex?
>>> A: It appears to offer insufficient benefit for the associated
>>>  complexity in typical usage.  A classic use case that argues for a
>>>  different endIndex type is the null-terminated C string.  But you
>>>  can't index one of those safely without actually counting the length,
>>>  and once you've done that you can make the endIndex an Int.
>> 
>> It’s also worth nothing that we can use `Optional` with `nil` as the `endIndex` sentinel if necessary.
> 
> I don’t believe this is true? Optional cannot support Equatable w/o generics changes. I believe we would need a different wrapper type.

That's true right now, but conditional conformances are very near the top, if not the top, item on the generics priority list.  I'm hoping they make Swift 3.x rather than 4.0 (but have no knowledge of the likelihood of that).

>>> The fact that Swift doesn't have a mutation model for classes, though,
>>> means that mutating methods on a class constrained protocol can't be
>>> labeled as such.  So consuming operations on a class-constrained
>>> Iterator protocol would not be labeled as mutating.
>>> 
>>> The standard library team is currently trying to evaluate the tradeoffs
>>> in this area.  One possibility under consideration is simply dropping
>>> support for single-pass sequences until Swift can support move-only
>>> value types and/or gets a mutation model for class instances.  It would
>>> be very interesting to know about any real-world models of single-pass
>>> sequences that people are using in Swift, since we don't supply any in
>>> the standard library.
>> 
>> I’m happy to see you mention a mutation model for class instances!  (I don’t mean to sidetrack the discussion, but would love to see that someday)
>> 
>> I don’t have any objection to dropping support for single-pass sequences temporarily.  It’s possible that I would feel differently if I was making use of them in my own code but I’m not.
> 
> I might see an issue if there were enough single-pass sequences that we worried about them trying to wedge themselves into Collection.
> 
>> In the meantime, people would be able to implement their own protocol for single pass sequences.  What they would lose is for..in as well as the standard library algorithms.  I’m not sure how many people this would impact or how big the impact would be for them.  We have seen a couple of examples in this discussion, but probably not enough to asses the overall impact.
> 
> I “feel” the model for Iterator as a separate possibly single-pass/infinite thing makes sense. But I also suspect unique requirements will come up for I/O use cases; who knows if some concurrency primitives might provide a better fit at that point in time?
> 
> -DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160705/f3dd8a78/attachment.html>