isInfinite isInadequate

[monarch_dodra]

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 
>> <deadalnix at gmail.com> 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?