On Tuesday, 12 March 2013 at 16:16:07 UTC, Andrei Alexandrescu
wrote:
On 3/12/13 11:47 AM, Steven Schveighoffer wrote:
On Tue, 12 Mar 2013 11:25:54 -0400, deadalnix
<[email protected]> wrote:
On Tuesday, 12 March 2013 at 10:49:57 UTC, monarch_dodra
wrote:
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.
Hm... is there a way to test for inifinitness without
requiring to be an
enum?
Wouldn't this also be valid?
if(!R.init.empty)
Essentially, you can evaluate R.init.empty at compile time AND
it's
false on an uninitialized range. How can a correctly written
non-infinite range pass that?
That would make forwarding much easier, as the 'dumb'
implementation
still would result in an infinite range.
Crossed my mind a few times that fresh non-infinite ranges
should be empty.
s/should/could/
In any case, that's a very dangerous logic to follow.
Not-initialized means not initialized. At that point, the concept
of empty or not empty is irrelevant, it's a wrong call.
By the same token, I don't think anybody would expect a call to
empty on a null class reference to actually succeed.
But there's no explicit requirement stating that, and I think
e.g. one may define a k-elements buffer backed by in-situ
storage.
Andrei
Not sure what you mean?
