In an answer to a question about std::stack::pop() I claimed that the reason pop does not return the value is for exception safety reason (what happens if the copy constructor throws).
@Konrad commented that now with move semantics this is no longer relevant. Is this true?
AFAIK, move constructors can throw, but perhaps with noexcept it can still be achieved.
For bonus points what thread safety guarantees can this operation supply?
Of course, not every type is move-enabled and C++0x even allows throwing move constructors. As long as constructing the object from an rvalue may throw it cannot be exception-safe. However, move semantics allows you to have many types that are nothrow-constructible given an rvalue source.
Conditional support for this could be done with SFINAE. But even without such a conditional member function nothing stops you from writing:
auto stack = ...;
auto elem = std::move_if_noexcept(stack.back());
stack.pop_back();
which is makes the strong exception guarantee even in case your move constructor doesn't give the strong guarantee.
As for the bonus question, that would offer no thread-safety. Consider that, as an example, most implementations of std::vector have three data elements (pointer to beginning of memory, pointer one beyond end of used data, pointer one beyond end of allocated memory). Move semantics allow you to move the contents of the vector without the need to reallocate and copy values, but that has nothing to do with thread safety. You would have to use thread-safe constructs to make the structure thread safe (as moving does not imply by any means atomic)