[libc++] Try and prevent evaluation of `is_default_constructible` on tuples default constructor if it is not needed.

[EricWF]

Summary

Currently parts of the SFINAE on tuples default constructor always gets evaluated even when the default constructor is never called or instantiated. This can cause a hard compile error when a tuple is created with types that do not have a default constructor. Below is a self contained example using a pair like class. This code will not compile but probably should.

#include <type_traits>

template <class T>
struct IllFormedDefaultImp {
    IllFormedDefaultImp(T x) : value(x) {}
    constexpr IllFormedDefaultImp() {}
    T value;
};

typedef IllFormedDefaultImp<int &> IllFormedDefault;

template <class T, class U>
struct pair
{
  template <bool Dummy = true,
    class = typename std::enable_if<
         std::is_default_constructible<T>::value
      && std::is_default_constructible<U>::value
      && Dummy>::type
    >
  constexpr pair() : first(), second() {}

  pair(T const & t, U const & u) : first(t), second(u) {}

  T first;
  U second;
};

int main()
{
  int x = 1;
  IllFormedDefault v(x);
  pair<IllFormedDefault, IllFormedDefault> p(v, v);
}

One way to fix this is to use Dummy in a more involved way in the constructor SFINAE. The following patch fixes these sorts of hard compile errors for tuple.

[ldionne]

The faulty code was mine. With the pair example, it is clear that all those is_default_constructible<T> are instantiated even when the default constructor is not. I think my intention when writing Dummy && is_default_constructible<_Tp>::value was to delay the instantiation of is_default_constructible<_Tp> as a compile-time optimization (which it fails to do), but not for correctness purposes.

However, looking at http://en.cppreference.com/w/cpp/types/is_default_constructible and then http://en.cppreference.com/w/cpp/concept/DefaultConstructible, I am unsure whether instantiating is_default_constructible<_Tp> should cause a hard error at all. If instantiating the default constructor in the expression

_Tp x{}

causes a compile-time error, should is_default_constructible<_Tp>::value be false or trigger a compile-time error?

Summary: At a glance, the fix seems correct in that it will properly delay the instantiation of the is_default_constructible<_Tp>s. However, is there a bug in is_default_constructible?

[rsmith]

include/type_traits

2649–2652

Is it worth generalizing / simpilfying this:

template <class _Tp, bool> struct __dependent : public _Tp {};

(Usage: __dependent<is_default_constructible<_Tp>, Dummy>::value)

[EricWF]

It's not yet completely clear whether Clang's (and GCC's) behavior is right here; there's an active core issue on how to handle this case.

GCC 4.8 and clang actually do the exact same thing on the example
code. What behavior are you referring to exactly?

Could you explain why the dependent type trick actually works? I'm
unsure as to why clang thinks it can evaluate one set of template
arguments but not the other even though it has essentially the same
information when evaluating tuple().

Also is clang ever going to outsmart this trick and realize
dependent<is_default_constructible<_Tp>, Dummy> is not actually
dependent on anything in this context? (ie on a default constructor)

Thanks for your input

/Eric

[EricWF]

Address Richard's comments. Create a generic __dependent_type template instead of using __dependent_is_default_constructible.

[ldionne]

In D7569#122353, @EricWF wrote:

Could you explain why the dependent type trick actually works? I'm
unsure as to why clang thinks it can evaluate one set of template
arguments but not the other even though it has essentially the same
information when evaluating tuple().

Let's take the pair example:

template <class T, class U>
struct pair {
  template <bool Dummy = true,
    class = typename std::enable_if<
         std::is_default_constructible<T>::value
      && std::is_default_constructible<U>::value
      && Dummy>::type
    >
  constexpr pair() {}
};

Because T and U are known when pair<T, U> is instantiated, regardless of
whether the default constructor is instantiated too, the above is equivalent to

template <class T, class U>
struct pair {
  static constexpr bool T_is_default_constr = std::is_default_constructible<T>::value;
  static constexpr bool U_is_default_constr = std::is_default_constructible<U>::value;

  template <bool Dummy = true,
    class = typename std::enable_if<
         T_is_default_constr
      && U_is_default_constr
      && Dummy>::type
    >
  constexpr pair() {}
};

So Clang can (and does) instantiate the is_default_constructible<T> as soon
as it can, which is as soon as pair<T, U> is instantiated. What I wrote for
std::tuple would then just be equivalent to:

template <class ..._Tp>
struct tuple {
  static constexpr bool _Tp1_is_default_constr = std::is_default_constructible<_Tp1>::value;
                            ...
  static constexpr bool _Tpn_is_default_constr = std::is_default_constructible<_Tpn>::value;

  template <bool Dummy = true,
    class = typename std::enable_if<
         _Tp1_is_default_constr && Dummy
      &&            ...
      && _Tpn_is_default_constr && Dummy
    >::type
    >
  constexpr pair() {}
};

At least, that's my analysis but I could be wrong.

Also is clang ever going to outsmart this trick and realize
dependent<is_default_constructible<_Tp>, Dummy> is not actually
dependent on anything in this context? (ie on a default constructor)

That's a really good question. I think it could, in theory. That's because
a constructor does not have a name, so it is impossible to call e.g.

tuple<int, char>::tuple</* Dummy = */false>()

Hence, I think in theory the compiler could say "hey you have template
parameters but it is _impossible_ to specify something else than their
default value, so let's substitute the parameters now". I'm not sure
what is said about that in the standard though; perhaps someone can
shed light on this?

Louis

[K-ballo]

include/tuple

514

Nitpick, no need to name _Up here.

test/std/utilities/tuple/tuple.tuple/tuple.cnstr/default.pass.cpp

39

Could this constructor be made ill-formed in a more obvious way? For instance, would a static_assert dependent on T achieve the same effect?

[EricWF]

Address @K-ballo's comments.

[EricWF]

Accepting. I think this is a candidate for post commit review.

include/type_traits

2649–2652

Probably.

include/tuple

         typename tuple_element<_Jp, tuple<_Up...> >::type&& get(tuple<_Up...>&&) _NOEXCEPT;
 public:
 
-    template <bool _Dummy = true, class _Up = typename enable_if<
-        __all<(_Dummy && is_default_constructible<_Tp>::value)...>::value
+    template <bool _Dummy = true, class = typename enable_if<
+        __all<__dependent_type<is_default_constructible<_Tp>, _Dummy>::value...>::value
     >::type>
     _LIBCPP_INLINE_VISIBILITY
     _LIBCPP_CONSTEXPR tuple()

include/type_traits

 struct __void_t { typedef void type; };
 #endif
 
+template <class _Tp, bool>
+struct _LIBCPP_TYPE_VIS_ONLY __dependent_type : public _Tp {};
+
 template <bool _Bp, class _If, class _Then>
     struct _LIBCPP_TYPE_VIS_ONLY conditional {typedef _If type;};
 template <class _If, class _Then>

test/std/utilities/tuple/tuple.tuple/tuple.cnstr/default.pass.cpp

     ThrowingDefault() { }
 };
 
+struct IllFormedDefault {
+    IllFormedDefault(int x) : value(x) {}
+    template <bool Pred = false>
+    constexpr IllFormedDefault() {
+        static_assert(Pred,
+            "The default constructor should not be instantiated");
+    }
+    int value;
+};
+
 int main()
 {
     {

         assert(std::get<0>(t) == 0);
         assert(std::get<1>(t) == nullptr);
     }
+    {
+    // Check that the SFINAE on the default constructor is not evaluted when
+    // it isn't needed. If the default constructor is evaluted then this test
+    // should fail to compile.
+        IllFormedDefault v(0);
+        std::tuple<IllFormedDefault> t(v);
+    }
 #endif
 }