Reimplementing RangeGenerator

[rick-de-water]

Description

The RangeGenerator was lost during the refactor of the generator interface. I've re-implemented it using the new generator interface. I have also extended it by adding an optional step size.

If it is satisfactory then I will update the documentation as well.

GitHub Issues

Disappeared in #1516

[codecov]

Codecov Report

Merging #1526 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1526   +/-   ##
=======================================
  Coverage   80.58%   80.58%           
=======================================
  Files         121      121           
  Lines        3383     3383           
=======================================
  Hits         2726     2726           
  Misses        657      657

[codecov]

Codecov Report

Merging #1526 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1526   +/-   ##
=======================================
  Coverage   80.54%   80.54%           
=======================================
  Files         121      121           
  Lines        3386     3386           
=======================================
  Hits         2727     2727           
  Misses        659      659

[JoeyGrajciar]

I think that it should be limited only for arithmetic types.

[rick-de-water]

I personally prefer to keep it open for anything that provides the correct interface. This way someone can still use it with their own classes, such as a BigInteger. A rare use case, but I think trying to prevent someone from putting a string in it isn't going to help anyone either.

But that's my opinion, if you really want me to I can always add a static_assert with std::is_arithmetic.

[JoeyGrajciar]

Add also a documentation and example for this.

[rick-de-water]

I have removed the possibility to use anything other than integers as requested.
The documentation has been updated as well.

[horenmar]

I am back.

Apart from the two lines with hard tabs, this looks good and definitely mergeable. However, I remember from Discord that you wanted the RangeGenerator to work with non-integral types, while I would really rather it didn't (because the step can be hard to define, or even plain wrong, for non-integral types, such as float).

I think we can compromise by forcing the helper to do the checking for integralness of the types -- doing so would ensure that users wouldn't be bitten by something like range(-2.0, 7.4, 0.1), while they would be able to say "trust me, I know what I am doing", and construct RangeGenerator directly, with an arbitrary type.

[horenmar]

I made the mentioned changes and squashed the PR together, gonna merge it later after it goes through CI.