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