is_move_constructible and msvc2013

#include <iostream>
#include <type_traits> 

struct Foo 
{
    Foo(Foo&& f) = delete;
};

int main()
{

    std::cout << std::is_move_constructible<Foo>::value; // output is 1

    std::cin.ignore();
}

Under msv2013 should I forgot something, or is there a bug ?

APPENDUM:

#include <iostream>
#include <type_traits> 

struct Foo 
{ 
    ~Foo(){}
};

int main()
{
    std::cout << std::is_move_constructible<Foo>::value;

    std::cin.ignore();
}

even with CTP this program produce an output of 1 (and c++ standard say the contrary), whereas the first example with CTP works fine.

Solution

Yes, it must be a bug.

is_move_constructible is defined in terms of is_constructible, which requires that a construction with the given parameters is well-formed, which is clearly not the case here.

[C++11: Table 49]: is_move_constructible<T>

is_constructible<T, T&&>::value is true

[C++11: 20.9.4.3/6]: Given the following function prototype:
template <class T>
typename add_rvalue_reference<T>::type create();
the predicate condition for a template specialization is_constructible<T, Args...> shall be satisfied if and only if the following variable definition would be well-formed for some invented variable t:
T t(create<Args>()...);

^{(A note that follows clarifies that create is used here to avoid the Most Vexing Parse for all Args.)}

For the record, the output is 0 with GCC 4.8.

A similar bug with is_*constructible relating to abstract classes appears to have been fixed in mid-2013, and here's another one:

Posted by Microsoft on 18/09/2013 at 13:17 Hi,

Thanks for reporting this bug. We've fixed it, and the fix is available in VS 2013 RC.

In fact, we've overhauled , fixing all known bugs. You can read more about this here: http://blogs.msdn.com/b/vcblog/archive/2013/06/28/c-11-14-stl-features-fixes-and-breaking-changes-in-vs-2013.aspx

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
[email protected]

The changelog behind that link includes the following fix:

the is_constructible family of type traits behaving incorrectly with references (DevDiv#517460)

So, give this a go again in MSVS's November 2013 CTP.

Update: I'm told that this is fixed in the November CTP. Thanks Andy Prowl for testing.