On Mon, Jun 22, 2020 at 08:53:22PM -0600, Jonathan M Davis via Digitalmars-d-learn wrote: [...] > Exactly. It's because of issues like this that generic, range-based > functions need to be tested with a variety of range types - including > reference types. Without that, bugs are routinely missed. [...] > If we do actually rework the range API as has occasionally been > discussed, it would be _really_ nice if we could more thoroughly > restrict the copying semantics of ranges so that some of these > problems go away, but without such a redesign, we're stuck with such > problems.
Redesign or not, I think the new range API should be much more specific in specifying exactly what behaviours ranges ought to have. The current API is under-specified, with two of the main problem points that I can remember being: 1) Transient-ness: is the value return by .front guaranteed to remain valid, or does .popFront invalidate it? This is not specified in the current spec, and we have ranges in Phobos of either type (e.g., iota and .byLine), with a lot of code just blindly assuming non-transience only to discover that things break down when handed a .byLine instance. 2) The exact semantics of copying (assigning) a range. What parts of a range's state is/isn't preserved when you assign a range to a local variable, for example? What happens if you pass a range to a function and then continue to operate on the original? All of this must be specified precisely in the range API so that we don't have one range acting one way and another range acting another way, thereby compromising the semantics of generic code. T -- Democracy: The triumph of popularity over principle. -- C.Bond
