[PATCH] [libcxx] SFINAE-friendly common_type

[Agustín Bergé]

================
Comment at: include/type_traits:1487
@@ +1486,3 @@
+
+// bullet 4 - sizeof...(Tp) > 2
+
----------------
EricWF wrote:
> I only see 3 bullets in http://cplusplus.github.io/LWG/lwg-defects.html#2408
That's right, the current wording with only 3 bullets regresses key functionality when it comes to user-defined specializations of `common_type`. The 4 bullet version was my suggestion to get the original behavior back. This is now being tracked instead by LWG2465, so we could wait for it to settle to move forward with this patch. Otherwise, I'd rather not have a sfinae-friendly `result_of` if that means regressing functionality.

================
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>
 {
----------------
EricWF wrote:
> We can skip an instantiation here and go straight to `__common_type2` right?
No, doing so would mean skipping over user-defined specializations of `common_type`

================
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...> > {};
----------------
EricWF wrote:
> 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.
> 
I'm not sure, will investigate.

http://reviews.llvm.org/D6964

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