On Sat, Mar 08, 2014 at 10:38:50AM +0100, Timon Gehr wrote: > On 03/08/2014 02:09 AM, H. S. Teoh wrote: > >On Sat, Mar 08, 2014 at 01:14:29AM +0100, Timon Gehr wrote: > >>On 03/07/2014 02:37 AM, H. S. Teoh wrote: > >>>Unfortunately, input ranges are somewhat tedious to write -- nice > >>>foreach loops have to be broken up into .empty, .front, .popFront, > >>>which is a lot of boilerplate code and not so nice in inner loops > >>>(though I suppose the idea is to improve compiler inlining to > >>>handle these cases). > >> > >>I think that the separation of front and popFront causes much of > >>this. > > > >I'm on the fence about that one. On the one hand, some ranges that do > >complex calculations in .front are better off with > >.popAndReturnFront. But on the other hand, there are also algorithms > >for which you don't want to advance the range just to pick off its > >front element. Since the separated semantics can't be achieved with a > >non-separated range API, I lean slightly towards favoring the current > >split approach. ... > > I agree that there are trade-offs involved. > > >Having a way to auto-generate input range boilerplate, though, would > >be really, *really* nice. Coroutine-style code would be ideal. > >... > > The drawback is that without the compiler being really clever, > ranges thus defined will be just input ranges.
We can achieve at least forward ranges with coroutines, if they're pure. T -- Your inconsistency is the only consistent thing about you! -- KD
