Ranges - Question about desing choices

[Michal Minich via Digitalmars-d-learn]

On Monday, 24 August 2015 at 17:17:16 UTC, Steven Schveighoffer 
wrote:
>> 3) it is not possible to "ask" a range if it's empty more 
>> times per
>> iteration of one item
>
> This isn't very composable. If I call a function that consumes 
> some number of items from a range, that function needs to 
> forward the information back to me of whether the range is now 
> empty or not.
>
That is a very good point. Non-existence of 'empty' property 
would have negative impact on composability and convenience of 
use if range is shared between alogorithms (For example in a 
parser). As you say that information would need to be transferred 
in program using another means. I see this composability aspect 
as critical, and for me it alone makes 100% case for the 
existence of 'empty' property.
>>
>> 4) it does _not_ requires range to be in "ready" state 
>> immediately after
>> construction. That means that popFront needs to be called 
>> firstly,
>> before front can be. This I feel is biggest change. Since D 
>> ranges are
>> required to have front ready immediately after their 
>> construction. Which
>> for some non trivial ranges can seem as less 
>> effective/convenient/expected.
>
> So on the flip side, ranges that *could* be ready as soon as 
> they are created, must store some state that says popFront 
> hasn't yet been called. I find this requirement to be a wash 
> implementation-wise, and actually a negative API wise, since 
> you as the consumer of the range must carry the burden of 
> storing whether it was empty the last time popFront was called.
>
> I would challenge you to write a wrapper for an array slice 
> (yes, you would need a wrapper, not just simple UFCS functions) 
> and see whether you think it's still worth it.
>
> -Steve

Ok. What about this: there exactly the same 3 primitives as in D 
range, but popFront is requred to be called first, before calling 
front, or empty properties. Why current approach against this?