If the float range uses a float iterator that is based on 'integer_iterator_with_step', the 'progress' of the iterator would be stored as an integer value, the step member variable. So iterator increment and equality are safe from floating point issues as the integer step value would be used. https://github.com/boostorg/range/blob/develop/include/boost/range/irange.hp... I was thinking of the Date type from <chrono>, not the one from Boost. Wim Leflere On Fri, Jan 10, 2020 at 1:05 PM Neil Groves wrote:

On Thu, 9 Jan 2020 at 21:45, Wim Leflere via Boost wrote:

...

Hello,

I was wondering why the (i)range function is limited to integers.

https://www.boost.org/doc/libs/1_72_0/libs/range/doc/html/range/reference/ra...

It would be nice if it also supported floats. Or any 'incrementable' class, e.g. Date.

Support for floating point was consciously not included since it would be highly likely to cause problems. The inequality of a float range would almost certainly require a predicate to consider the appropriate epsilon. We could have coped with the precondition constraints for rejecting NaN but the inequality predicate problem means a different interface. I therefore concluded it was not a priority. I am of the current opinion that it is of very little value, and potentially negative utility to provide this in Boost.Range.

For Date since Boost.DateTime provides the TimeIterator one can create a range. There is a general idioms for creating ranges from iterators see make_iterator_range, iterator_range, sub_range etc. Hence the specific name is not provided since it is not required.

The reason I did not generally support making a range from an Incrementable is because Incrementable is necessary but not sufficient.

...

Regards, Wim Leflere

HTH, Neil Groves