Why is ranges::ostream_iterator default-constructible?

Question

_{This question follows a discussion in the comments here.}

In Eric Niebler\'s ranges-v3 library (which is sort-of becoming part of the standard for C++20),

Answer 1

There are a lot of things in C++ where a non-default-constructible type is simply not workable. Here's a really simple example: extract a type T from an istream using the >> operator without default constructing T (or otherwise being given a live T). You can't, because the interface itself requires that one exists. The interface is designed to assume that you can always construct an object of an extractable type.

And if you're not given an object to work with, that means default constructing it.

This seems like a cherry picked example, but it isn't. It is a semi-frequent occurrence that in generic code, you sometimes need to just create a T so that you can fill bits of it in later.

However much we would like to say that objects should only be default constructible if it is meaningful for them to be in such a state, it simply is not a practical reality. Sometimes, you just have to create an object now and get it filled in with a useful value later.

As such, the Ranges v3 library enshrines this requirement in the basic and frequently used concept SemiRegular. That concept represents some of the more basic aspects of manipulation for objects: I can make one, and I can assign it. Iterators are required to follow that concept.

---

It should also be noted that, in C++20, ostream_iterator gains a default constructor.