On Sunday, 6 November 2022 at 01:48:04 UTC, Walter Bright wrote:
> We didn't use the "next" protocol for ranges because one cannot test for existence of the next element without consuming it.

Aren't there cases (e.g. some kinds of IO) where that's unavoidable in any case?

The "next" approach is surely the most information-limited case, where you really can't separate between checking for existence of the next element, and consuming it.  Other possibilities, such as the presence of a check whether the range is `empty`, or the possibility to `peek`, would then be less information-limited options on top of that.

I apologize if I'm out of date on some discussions which have already taken place around the range design, and so forcing you to re-explain something that's already been worked through.

On Thursday, 10 November 2022 at 15:25:30 UTC, Joseph Rushton Wakeling wrote:
> Other possibilities, such as the presence of a check whether the range is `empty`, or the possibility to `peek`, would then be less information-limited options on top of that.

BTW, note that the `empty` check is a more information-limited version of peekability.  For example, an algorithmic range (such as a range-based view of random number generation) can tell you that it's not empty, but may not be able to tell you what the next value will be.

OTOH I would imagine that most (all?) ranges across the contents of containers should be able both to tell you if the range is empty or not _and_ allow you to peek at the next in sequence.

On Thursday, 10 November 2022 at 15:25:30 UTC, Joseph Rushton Wakeling wrote:
> On Sunday, 6 November 2022 at 01:48:04 UTC, Walter Bright wrote:
>> We didn't use the "next" protocol for ranges because one cannot test for existence of the next element without consuming it.
>
> Aren't there cases (e.g. some kinds of IO) where that's unavoidable in any case?
>
> The "next" approach is surely the most information-limited case, where you really can't separate between checking for existence of the next element, and consuming it.  Other possibilities, such as the presence of a check whether the range is `empty`, or the possibility to `peek`, would then be less information-limited options on top of that.
>
> I apologize if I'm out of date on some discussions which have already taken place around the range design, and so forcing you to re-explain something that's already been worked through.

Yes, in some cases you have to consume the inner stream in either the constructor or in the empty call. I would also like for a more simpler range with only `next`.