2014-12-02 14:08 GMT+01:00 John Maddock :

#include

...

#include

struct NothrowCtor { NothrowCtor(NothrowCtor&&) BOOST_NOEXCEPT_IF(true) {}; void operator=(NothrowCtor&&) BOOST_NOEXCEPT_IF(false) {}; };

BOOST_STATIC_ASSERT(!::boost::is_nothrow_move_assignable< NothrowCtor>::value);

int main() {}

Update: in the absence of SFINAE expression support, a number of type_traits are terminally broken, and this is one I'm afraid.

If this is unimplementable, then that's fine. What I find confusing is that regression tests for is_nothrow_move_assignable pass on this compiler: http://www.boost.org/development/tests/develop/developer/type_traits.html

...

...

Update: in the absence of SFINAE expression support, a number of type_traits are terminally broken, and this is one I'm afraid.

If this is unimplementable, then that's fine. What I find confusing is that regression tests for is_nothrow_move_assignable pass on this compiler: http://www.boost.org/development/tests/develop/developer/type_traits.html

The compiler has an __is_nothrow_assignable() built-in, which seems usable here.

The standard says that is_nothrow_move_assignable<T> is the same as is_nothrow_assignable.

Will investigate. BTW the current implementation does use noexcept - the issue is that in some situations this leads to noexcept(expression-that-doesn't-compile) which requires SFINAE-expression support. John.

2014-12-05 19:33 GMT+01:00 John Maddock :

The compiler has an __is_nothrow_assignable() built-in, which seems

...

...

usable here.

The standard says that is_nothrow_move_assignable<T> is the same as is_nothrow_assignable.

Will investigate.

is_nothrow_move_assignable/constructible should now be fixed for msvc-12 and later in develop.

Thanks! When can we expect it in branch master?

[Bo Persson]

The compiler has an __is_nothrow_assignable() built-in, which seems usable here.

Yeah, that's what VC's STL uses. Specifically: * Obviously library-only type traits are implemented with library code. * "Derived" type traits like is_nothrow_move_assignable are implemented in terms of "base" type traits like is_nothrow_assignable, as depicted by the Standard. * "Base" type traits are implemented by invoking compiler hooks directly. In previous versions, the STL sometimes compensated for compiler hooks behaving differently than the Standard Library's requirements, but over the years we've gotten compiler changes so we can just return whatever the hooks do. The only exceptions to this rule (that I can think of right now) are is_assignable (which probably *should* be powered by a hook like its trivial/nothrow cousins, but instead is written with Expression SFINAE by special dispensation) and aligned_storage/union (which cannot be powered by alignas yet; it uses library tech instead). The compiler hooks are undocumented, but because the STL uses them, Boost can use them too. Please report any bugs you encounter so both libraries can benefit. (The compiler team has been fixing several reported bugs in the hooks; 2015 RTM will report more accurate answers than ever before.) STL