The Standard library containers in C++ have constructors that take iterator ranges. This is handy when the content of an input container is convertible to, but not the same as the content in the resulting container, or even if the container is just different. The constructor overload allows for this type of conversion to happen in a surrounding class's constructor, which leads to less clutter in the code.
So the question arises, why don't the Qt containers have this overload? Is it an oversight or is there a reason behind this clunky design choice?
There is no reason except for "nobody implemented them so far", as the Qt Project doesn't have an infinite development bandwidth.
Speaking of such missing features, you could say the same for:
QList::push_back(T &&));QList having no equivalent in the STL and being a very strange monster with serious performance issues. It is now acknowledged that it should have never been made the "good generic container" used everywhere in Qt;and so on.
There's lots of discussion going on these days (f.i. see this thread) about the poor state of Qt containers when compared to the STL ones, to the point that we're starting using STL containers in Qt's own implementation.
Unless you have specific reasons for using the Qt ones (say, you need to pass them to Qt-ish APIs, or you like/need implicit sharing, etc.), these days STL containers are way better than Qt ones.
Update: QList in Qt 6 is going to be a proper vector, and QVector (In Qt 6) will be an alias to QList. Some of the remarks above will not apply any more. I'm not modifying the rest of the answer as that still applies to Qt 5.15.