Downgrading ranges

Andrej Mitrovic andrej.mitrovich at gmail.com
Sun Jun 9 06:01:42 PDT 2013


On 6/9/13, Lars T. Kyllingstad <public at kyllingen.net> wrote:
> Example:
>
> enum RangeFeatures
> {
>      input,
>      forward,
>      randomAccess,
>      ...
> }

Well, those are range *types*, not features. So name it RangeType perhaps.

Alternatively:

enum RangeFeatures
{
     emptyEnum,  // e.g. enum bool empty = true;
     emptyProperty,  // e.g. @property bool empty() { }
     indexable,  // e.g. range[0]
     sliceable,  // e.g. range[]
     hasFront,
     hasPopFront,
     hasBack,
     hasPopBack,
     hasSave,
}

And then autogenerate all of those somehow.

Or just provide simple wrappers ala "toInputRange", "toBidirectionalRange", etc.

Long story-short I do think we need these simulation ranges in
std.range, exactly for unittesting purposes. There is a lot of
throwaway range implementations in unittest blocks in Phobos (and many
other libraries) used for the sole purpose of unittesting. It would be
much simpler to be able to use "testMyFunction([1, 2,
3].toInputRange)" or something to that effect.


More information about the Digitalmars-d mailing list