[PATCH] [libcxx] SFINAE-friendly common_type

[Eric Fiselier]

Just so I'm sure I understand: This implementation applies `decay<T>`  for ever pair of types in `common_type<T...>` even though N2408 says `decay` is only applied to the final type?


================
Comment at: include/type_traits:1478
@@ -1477,1 +1477,3 @@
+struct __common_type2<_Tp, _Up,
+    typename __void_t<decltype(true ? declval<_Tp>() : declval<_Up>())>::type>
 {
----------------
I think we need to qualify the `declval<Tp>` calls so they don't use ADL.

================
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...> > {};
----------------
K-ballo wrote:
> 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.
I think I found the bug that tracks this: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1432 . Could we work around it for now?

http://reviews.llvm.org/D6964

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