[ Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which was subsequently split out into a separate paper N2436 for the purposes of voting. The resolution in N2436 addresses this issue. The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. ]

[ post Oxford: This would be rendered NAD Editorial by acceptance of N2257. ]

Proposed resolution:

Change [allocator.members]:

pointer address(reference x) const;

-1- Returns: &x. The actual address of object referenced by x, even in the presence of an overloaded operator&.

const_pointer address(address(const_reference x) const;

-2- Returns: &x. The actual address of object referenced by x, even in the presence of an overloaded operator&.

Duplicate: 350

[allocator.members] says:

pointer address(reference x) const;

-1- Returns: &x.

[allocator.members] defines CopyConstructible which currently not only defines the semantics of copy construction, but also restricts what an overloaded operator& may do. I believe proposals are in the works (such as concepts and rvalue reference) to decouple these two requirements. Indeed it is not evident that we should disallow overloading operator& to return something other than the address of *this.

An example of when you want to overload operator& to return something other than the object's address is proxy references such as vector<bool> (or its replacement, currently code-named bit_vector). Taking the address of such a proxy reference should logically yield a proxy pointer, which when dereferenced, yields a copy of the original proxy reference again.

On the other hand, some code truly needs the address of an object, and not a proxy (typically for determining the identity of an object compared to a reference object). boost has long recognized this dilemma and solved it with boost::addressof. It appears to me that this would be useful functionality for the default allocator. Adopting this definition for allocator::address would free the standard of requiring anything special from types which overload operator&. Issue 580 is expected to make use of allocator::address mandatory for containers.