On 06/03/2016 01:49 PM, Andrei Alexandrescu wrote: > On 6/3/16 4:37 AM, Dicebot wrote: >> Really, many of those issue would have been solved if basic input range >> was defined as `empty` + `ElementType popFront()` instead. > > FYI that was on the table, along with many other possible designs. > (popFront() should be allowed to return by reference, too.) The problem > with this one is that it is inefficient with arrays when the same > element is accessed multiple times - the user is forced to create a copy > or to use other contortions. Arrays are a prime use case for the range > interface. -- Andrei
Has it actually been measured as inefficient? Ranges are very inline/optimization friendly because of the templated nature of algorithms - I would expect at least GDC/LDC to take advantage of that for simple case and for more complicated ones mutiple evaluations of `front` predicates will dominate performance gain from direct array access. I guess I need to benchmark it myself and see :)