> On Jul 1, 2016, at 9:59 AM, Matthew Johnson via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Jun 30, 2016, at 12:26 PM, Dave Abrahams <[email protected]> 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.
>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
