[PATCH] [libcxx] SFINAE-friendly common_type

Eric Fiselier eric at efcs.ca
Tue Feb 10 18:25:21 PST 2015


LGTM as far as LWG2408. I'll look at LWG1255 tomorrow.


================
Comment at: include/type_traits:1487
@@ +1486,3 @@
+
+// bullet 4 - sizeof...(Tp) > 2
+
----------------
I only see 3 bullets in http://cplusplus.github.io/LWG/lwg-defects.html#2408

================
Comment at: include/type_traits:1496
@@ -1488,1 +1495,3 @@
+struct __common_type_impl<__common_types<_Tp, _Up, _Vp...>,
+    typename __void_t<typename common_type<_Tp, _Up>::type>::type>
 {
----------------
We can skip an instantiation here and go straight to `__common_type2` right?

================
Comment at: include/type_traits:1501-1502
@@ -1491,1 +1500,4 @@
 
+template <class _Tp, class _Up, class ..._Vp>
+struct _LIBCPP_TYPE_VIS_ONLY common_type<_Tp, _Up, _Vp...>
+    : __common_type_impl<__common_types<_Tp, _Up, _Vp...> > {};
----------------
Isn't there a core language defect about the following specializations being ambiguous? Something along the lines of this? 

```
template <class ...> struct Foo;

template <class T> 
struct Foo<T> {}; // Specialization 1

template <class T, class ... Args>
struct Foo<T, Args...> {}; // Specialization 2

using MyFoo = Foo<int>; // The defect is that both 1 and 2 match.

```

As far as I know it is accepted by all compilers but I just wanted to bring this up.

http://reviews.llvm.org/D6964

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the cfe-commits mailing list