Andrey Semashev wrote:
Well, there is function_output_iterator also, I kind of like the duality.
Each name has supporters ;)
I'm a bit worried if this could cause backward compatibility for users if they upgrade from a release with the old generator_iterator.
Non-default constructors for function_input_iterator and generator_iterator are incompatible; function_input_iterator has binary constructors and generator_iterator has unary constructors. Even if we add unary constructors that take only generator to function_input_iterator, they are incompatible; function_input_iterator accepts lvalue objects or function pointers and generator_iterator accepts pointers to objects but not function pointers. So, when upgrading from old generator_iterator to new one (i.e. function_input_iterator), there should be compilation failures. We can add the following constructor to help migration: class new_generator_iterator { new_generator_iterator(PointerToObject) { static_assert(false, "The implementation of generator_iterator has changed. " "Please consult the documentation to see how to update the code."); } }; However, if users of old generator_iterator rely on behaviors of the eager generation and of the equality operators, then the migration is hard to achieve. OK... I drop this idea. Range users may not care much about the name of underlying iterators; it would be OK if range constructs have standard names. I'll submit a PR that implements `generation` (the name `generate` is already used for range algorithms, so I use the name `generation` which is used in the Oven range library) to Boost.Range, which looks like template <typename Func, typename Count> inline auto generation(Func& f, Count cnt) { return make_iterator_range( make_function_input_iterator(f, Count()) , make_function_input_iterator(f, cnt) ); } template <typename Func> inline auto generation(Func& f) { return make_iterator_range( make_function_input_iterator(f, infinite{}) , make_function_input_iterator(f, infinite{}) ); } Regards, Michel