First of all, thank you for your reply and sorry for a bit lengthy post.

...

I'd like to ask if boost::addressof is going to be proposed to be included in the upcoming C++ Standard. And what is more important to me, will it solve the problem of storing objects with custom operator& in STL containers and acquiring their addresses with std::allocator<T>::address.

As of last week, it looks like std::allocator<T>::address will supply the functionality of boost::addressof. This is LWG issue 634:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#634

It's nice to see it, thanks for the link.

I'm afraid my answer amounts to: we're seriously considering it; maybe. :-\

Perhaps I should turn this around and ask you a question: What motivating use cases (of yours) can I bring to the committee to affirm our current position that value_type's with overloaded operator& can be put into the standard containers?

Well, actually I don't quite realize the cause of this restriction in the first place as I don't see why would the CopyConstructible requirement need to impose a denial of the operator& overload. Anyway, here's a real life example. In our company we had a long struggle against storing ATL types, like CComBSTR and CComPtr, directly in STL containers since the STL implementation we used compiled it silently but leaked the resources in the runtime (it just didn't call destructors of those classes, thinking that it destructs raw pointers returned by their operator&). I understand that our developers were wrong by not reading MSDN thoroughly, and that our STL implementation could have been more friendly, and ATL could have been made differently, and... But it's the fact that such a behavior is stated legal by the Standard that bugs me. We have spent months in hunting down those leaks, retesing and rereleasing our product, we've put significant effort in developing instruments to detect them and integrating those tools into our code. We've updated our questionnaire for the new employees (which, BTW, showed that a great deal of aspirants, just not to say majority of them, have no idea of this STL limitation) and drew attention to the issue of our current developers. And still, as we were switching to a new STL implementation recently, we were still finding several places in our code with this problem. Another good motivating example, a bit theoretical nowdays though, is implementing smart-references, along with smart-pointers. I see you mentioned them in your proposal regarding allocator.address() and I saw them mentioned in some different proposals. I think it would be a good idea to have the ability to store them in containers, like we can do with reference_wrapper and shared_ptr now. As I see it, there are three major points to allow storing types with user-defined operator& in containers: * The CopyConstructible concept should deal with the ability to create a copy of an object. It should not involve any third-party functions like operator&. If it can be overloaded, assume it is. And this fact does not interleave with the ability to call the object's copy constructor. * Same goes with containers. Their primary job is to store objects and while doing this they should call minimum of user-defined functions (thus imposing minimum set of requirements on types that can be stored). It should be assumed that operator& may be overloaded and is not suitable to acquire the address of the stored object for the internal needs of the container (for example, to destroy the object). I think, it would be natural to use allocator facilities for this purpose. * The restriction is counter-intuitive. This makes C++ a little more complicated than it could be. My practice have shown that this issue can, actually, impose serious problems on the users' side, both in writing the code and in learning the language.