Mathias Gaunard wrote:
Andrei Alexandrescu wrote:
Now here comes an interesting possibility. Boost::RangeEx also defines a typename Boost::RangeEx::iterator, and begin() and end() that return iterators. But it makes them optional! Meaning, as much as there are forward vs. bidirectional ranges, there are ranges that cloak iterators versus ranges that don't.
Would there be any reason for a range not to provide iterators except those iterators being hard to write?
In case there is none, I don't think it's such a good idea to use concept refining for a non conceptual difference, but rather an implementation difficulty.
It's not only implementation difficulty. I have many ranges that make next no sense as iterators. For example I have a range that spits out random numbers. The notion is very easy to fathom as a range, but forcing it into the iterator framework would be forced for the designer as well as the user of the notion. The design would be a net loss for everybody if it were required to define an iterator. Andrei