Have you found any need to support member functions of containers of incomplete types?
I don't think there is any need for that. What really matters is the memory layouts, i.e., to be able to form sizeof(container<T>) and sizeof(container<T>::iterator) and so on for other iterators. I really haven't encountered nor am I able to think of any context where you would need to write code that uses members of a container of incomplete types (or of an iterator thereof). It's very easy to move code around or to correctly place the instantiation points of the code to where all types are complete, it's really the memory layout that is nearly impossible to form safely if you have to work around an incomplete type problem. Just like having pointers to incomplete types doesn't allow you to really do anything with them (e.g., pointer arithmetic) until the type's completed, but what matters is that you can **form** pointer variables. It would be tedious and tricky to guarantee that specific members will work for incomplete types, and it might significantly restrict the implementation. Thanks for merging my commit. BTW, while testing my new BGL code against the current branch of Boost.Container, I also discovered that many of my unit-tests trigger infinite memory-leaking loops (when sets or lists are used as containers), which was not the case against version 1.54 of Boost.Container. It will take some time to track down where this is coming from, but if it comes from Boost.Container, you'll hear from me again about fixing those bugs ;) (N.B.: it's very possible that the errors are on my side of things, not yours, but I need to investigate it first). Mikael.