I've found that PIMPL-like idioms might require at least some operations (like the default constructor) to be incomplete type friendly.
Yes, that sounds reasonable. It could be reasonable to guarantee that default constructors (and assignment, maybe) can be possible for incomplete types. I guess in the same way as a pointer to an incomplete type can provide some basic operations (create a pointer, init to NULL, copy the pointer, etc.). It could make sense to just transpose whatever guarantees the standard gives for pointers of incomplete type to the container and iterator types as well. But I don't think it should or could go much beyond that.
Boost.Container has suffered a lot of changes recently, and it might surely be a Boost.Container bug.
Actually, I investigated a bit, and the problem stems from a rather embarrassing oversight on my part. I was using default-constructed iterators as a kind of universal "null iterator". This means that my code was riddled with undefined behavior as a consequence of that. It just happened to work on Boost.Container containers prior to the SCARY iterator changes. So, I was going to ask if it could be considered to add some guarantee that default-constructed (value-initialized) iterators have a well-defined "null" value (similar to default-constructed standard stream-iterators). Then, I noticed that proposal n3644 proposes exactly that, and it was accepted to C++14. See proposal "Null Forward Iterators": http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2013/n3644.pdf Therefore, this needs to be added to Boost.Container containers as well for compliance with C++14. I would be happy to do it myself, but I'm afraid that the whole under-the-hood iterator architecture used by Boost.Container and Boost.Intrusive is too much for me to wrap my mind around just for a purpose of adding a well-defined default-constructor. It should be a very simple fix for someone who already knows the code-base well. Right? Thanks, Mikael.