[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