On Tue, 12 Mar 2013 11:02:43 -0400, monarch_dodra <[email protected]>
wrote:
On Tuesday, 12 March 2013 at 14:30:00 UTC, Steven Schveighoffer wrote:
On Tue, 12 Mar 2013 06:49:56 -0400, monarch_dodra
<[email protected]> wrote:
On Tuesday, 12 March 2013 at 10:01:38 UTC, deadalnix wrote:
I want to resurrect that thread. Can someone explains the benefices
of isInfinite ? I fail to see how it really benefit the code.
The advantage of "enum empty = false" is that algorithms gain a great
performance boost by optimizing out any "if (r.empty)". This can be
exploited for things like take, or anything that iterates as a matter
of fact. I don't think anybody will argue that this is a bad approach.
Wouldn't it automatically be optimized out? I mean if r.empty is an
enum, it's like saying if(false) I would think even with optimizations
off, this might be done.
Not that I'm questioning the value of isInfinite (I'm neutral on it),
but this is not a benefit.
-Steve
Right, that's what I said. This first paragraph was just about enum
empty = false.
Oh, ok. When you said "optmizing out" I thought you meant using
isInfinite to optionally remove calls to empty by hand.
Another point: isInfinite is useful, if only to propagate infiniteness.
For example: "1.repeat().map"a * 2"()". If "map" didn't know that repeat
is infinite, it would simply provide the "dumb" empty implementation,
and the final range will have lost it's infinite trait.
With inlining, this should propagate properly:
struct WrapperRange(R)
{
R src;
@property auto front() { return src.front;}
@property bool empty() { return src.empty;} // should be optimized to
'false' with inlining
void popFront() { src.popFront();}
}
If R's empty is an enum, then WrapperRange's empty should inline to the
enum also.
-Steve
