Range Redesign: Empty Ranges

[H. S. Teoh]

On Wed, Mar 06, 2024 at 01:03:35PM -0700, Jonathan M Davis via Digitalmars-d wrote:
[...]
> My current plan is to retain std.range.interfaces in some form or
> another so that we can have ranges as classes as far as their
> implementation goes (at my job, we actually have to use classes for
> ranges, because we have to be able to wrap arbitrary ranges at
> runtime, since we're dealing with an intepreter). However, they would
> not count as ranges by any range-based algorithms, because they would
> be classes, and so they would have to be wrapped in structs to
> actually be used as ranges. The wrapper structs would then do all of
> the work to ensure that the proper copying behavior was implemented.
[...]
> So, unless I'm missing something here, we _should_ be able to just
> wrap classes in structs to allow ranges which are implemented as
> classes even if the classes themselves can't be ranges any longer. The
> net result should be that dealing with forward ranges is simpler, and
> we stop having save-related bugs, but we shouldn't actually lose any
> functionality.
[...]

This actually sounds like a reasonable approach.


T

-- 
Applying computer technology is simply finding the right wrench to pound in the correct screw.