Lots of low hanging fruit in Phobos
H. S. Teoh
hsteoh at quickfur.ath.cx
Sat Mar 8 07:31:42 PST 2014
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
More information about the Digitalmars-d
mailing list