I experienced some issues and asymmetric behavior in the function input and output iterator interfaces [1] [2]. See the following small self-contained example: const auto two = make_function_input_iterator([]{ return 2; }, infinite{}); copy_n(two, 3, ostream_iterator<int>(cout, "\n")); This does not compile --- but it should, in my opinion. The problem is that make_function_input_iterator has two overloads, one that takes a Function& and one that takes a Function*. Shouldn't this rather take a Function by-values as the stdlib does, and let the user pass a std::ref if needs be? Then we could also pass lambdas, making this a viable feature in C++11 and later. Without being able to pass lambdas, I see almost no value in the input iterator. On a related note, the documentation does not say that the make_function_iterator always needs an Input state. In addition, the link to the function input iterator PDF on the overview page [3] 404s. Now to the function output iterator: const auto dummy_out = make_function_output_iterator([](int) {}); copy_n(nums, 3, dummy_out); Surprisingly this compiles since make_function_output_iterator takes its functor by const-ref (with a defaulted functor argument, which does not really make sense in my opinion, since the reason for the make_* function is type inference through the passed parameter). Note, though, how the function output iterator lives in the same iterators namespace as the functio input iterator, but is not inside the iterator directory. The respective headers are located at: boost/function_output_iterator.hpp boost/iterator/function_input_iterator.hpp I would love to understand the design decisions behind these, and if it would be possible to "modernize" them without breaking much of the interfaces. Cheers, Daniel J H [1] http://www.boost.org/doc/libs/1_59_0/libs/iterator/doc/function_input_iterat... [2] http://www.boost.org/doc/libs/1_59_0/libs/iterator/doc/function_output_itera... [3] http://www.boost.org/doc/libs/1_59_0/libs/iterator/doc/index.html