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. 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). 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??? _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
