On Tuesday, 12 March 2013 at 10:49:57 UTC, monarch_dodra 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.
I think the point is moot for the same reason it is for
SentinelRange. A function that return false will be inlined and
the whole if optimized away anyway. Same goes for a constant.
I'm not talking about a supposed sufficiently smart compiler, but
actual compiler that exist right now.
The trait itself checks if empty can be evaluated at compile
time (to false). The advantage for the *coder* to know if the
range is infinite is less obvious.
One of the advantages is that an infinite range can have random
access (meets RA requirements), even though it has no length
member (normally, any RA range must have length).
Having "isInfinite" can also have the advantage of protecting
users from stupid calls. For example, calling "count" on an
infinite range is forbidden => shifting problems from runtime
to compile time is a HUGE gain.
Clearly this is a good point. I however think that a static
assert within count is much better because it allow to give nicer
feedback. The problem with InfiniteRange is that it does gives
you cryptic error message like the count function do not exists.
One of downsides to having infinite ranges is that their
existence tends to make dealing with generic RA ranges a bit
more difficult. A lot of our algorithms have changed
requirements conditions from:
"if (isRandomAccessRange!R)"
to
"if (isRandomAccessRange!R && hasLength!R)"
or
"if (isRandomAccessRange!R && !isInfinite!R)"
//NOTE: Both are strictly equivalent: An RA range is either
infinite, or has length, but not neither nor both.
Up until not so long ago, it was not possible to slice infinite
ranges. It is now possible. Unfortunatly, because RA ranges
with slicing don't guarantee that r[0 .. $] is legal, things
are still complicated in template code.
I conclude that the fix introduced complexity without solving the
problem, just pushing the limit. I think we should avoid this
kind of stuff.
The last point (IMO minor) that is raised in the thread is
"runtime" infiniteness. EG: a range that may or may not be
infinite at compile time, but which will be known at runtime.
IMO, these a rare enough (arguably, inexistent) to not really
matter. The workarounds are easy:
1) Make the range always infinite, but with a requirement that
user must intialize it or whatnot.
2) Make a runtime fork that will call code that operates on a
compile-time known infinite adaptor/subtype.
A common case is unknown "infinitivenes".
