On Sunday, April 15, 2018 10:14:20 Dmitry Olshansky via Digitalmars-d wrote: > On Sunday, 15 April 2018 at 06:39:43 UTC, Jonathan M Davis wrote: > > On Sunday, April 15, 2018 07:26:54 Shachar Shemesh via > > > > Digitalmars-d wrote: > >> [...] > > > > It's extremely common for range-based functions to copy front. > > Even foreach does it. e.g. > > > > [...] > > Arguably it should “move” them. > > This would have worked if input ranges didn’t have to cache front > to support multiple ‘front’ calls before popFront. Which is a > painful misfeature really as all algorithms would optimize for > touching front once anyway. > > Input range should “produce” elements not keep cache of them, > forward ranges may cache current item alright.
If that were the route that we were going to go, then front and popFront wouldn't make any sense at all. Rather, you'd treat it more like in iterator in Java and have next() return the next element and pop it off at the same time. But even if we did that, it wouldn't have been appropriate in the general case to move the element unless we put serious restrictions on what could be an input range (e.g. that would make no sense whatsoever with dynamic arrays or any kind of container). In some respects it would be nice if input ranges were completely separate beasts from forward ranges, since ideally, forward ranges would all be value types, and input ranges would all be reference types (in which case, save wouldn't be a thing), but that would cause it's own set of problems, because then it wouldn't really work to have input ranges and forward ranges use the same code, which could get really annoying. Input ranges are kind of an abomination IMHO , because they're so painfully limited, but unfortunately, it simply doesn't work to have all ranges be forward ranges if you don't want to have to do stuff like buffer data. So, figuring out what we would ideally do with input ranges and forward ranges gets to be a bit of an interesting question. Regardless, even if we could all agree on how ranges would ideally be redesigned if we were doing this stuff from scratch, we're not doing it from scratch, and for better or worse, a lot of existing code depends on the current design. So, while I'd love to have the opportunity to sit down and redesign the range API, I don't see how we really can - not and actually have it implemented as part of the language or Phobos anyway. - Jonathan M Davis