on Mon Jun 27 2016, Anton Zhilin <[email protected]> wrote: > Dave Abrahams via swift-evolution <swift-evolution@...> writes: > >> I should be clear up-front about the main problem I'm trying to solve: >> >> Today, people see a beautiful, simple protocol (Sequence) to which many >> things conform. They don't recognize that there's a semantic restriction >> (assume you can make only a single-pass!) on it, so they write libraries >> of functions that may make multiple passes over Sequences. They test >> their libraries with the most commonly-available Sequences, e.g. Arrays >> and Ranges, which happen to be multi-pass. Their tests pass! But their >> constraints are wrong, their whole model of how to write generic code >> over sequences is wrong, and some of their code is wrong. > > This is a mistake that I see more often than I want to: designers of > development tools underestimate abilities of developers, and end up > restricting many of them.
In what way am I underestimating the abilities of developers? > My point is that we should impose minimal requirements on custom data > types. Quoting yourself: > >> In this case, protocols used to interface with the language >> at the lowest levels may be purely about syntax. > > So there should be a protocol for building into for-in loops that > requires only that the sequence should be iterable once. Currently, we > have Sequence for that. If we remove destructive consumption from > Sequence, then there should be a super-protocol SinglePassSequence or > Forinable (excuse the pun). Yes. > But even if we do this, I still don't understand the intentions. If a > Sequence is multi-pass, then we can satisfy requirements of > Collection, as already noted in the discussion. Why should we keep > Sequence at all, then? Then let's remove it and rename > SinglePassSequence to Sequence??? This kinds of decisions are all part of the discussion. -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
