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.

Reply via email to