[RFC] Removal of allocator::construct / destroy vs our containers

[Paolo Carlini <pcarlini at suse dot de>]

Hi,

in Oxford the removal of those allocator members has been decided. 
Immediately, people figured out that, for compatibility with existin 
user code a good path would be not actually removing the members from 
the  delivered allocators, but stop as soon as possible calling those 
member functions from the containers (in fact, the *current* standard, 
nowhere mandates that those members must be called): certainly, in the 
case of v3, that would mean a nice semplification of stl_construct.h, 
stl_uninitialized.h and many container headers. It would also mean, 
unless i'm badly confused, not risking at all passing around by value 
allocators only because allocator::construct and destroy are 
non-constant members.

Can you imagine problems with such a plan? Do we have principled reasons 
to delay it to when a full C++0x implementation of the library will be 
delivered?

Thanks,
Paolo.