[PATCH] [libcxx] SFINAE-friendly common_type

Eric Fiselier eric at efcs.ca
Thu Apr 30 23:04:55 PDT 2015


Even though this in no-where close to perfect (because we don't know how to specify common_type)  I think this is a strict improvement to what we have now for 3 reasons:

1. It makes common_type SFINAE friendly.
2. It properly supports common_type<void, void>
3. It properly supports user defined specializations (unlike N2408).

I'm can't decide on whether we should keep applying decay to the result of every ternary expression or adopt the new behaviour of only decaying the final result. However since this patch maintains the existing behaviour I think we should apply it until the committee comes to a consensus about what to do.

@K-ballo: Are you still willing to work on this?


================
Comment at: include/type_traits:1453
@@ -1452,12 +1452,3 @@
 {
-private:
-#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
-    static _Tp&& __t();
-    static _Up&& __u();
-#else  // _LIBCPP_HAS_NO_RVALUE_REFERENCES
-    static _Tp __t();
-    static _Up __u();
-#endif  // _LIBCPP_HAS_NO_RVALUE_REFERENCES
-public:
-    typedef typename remove_reference<decltype(true ? __t() : __u())>::type type;
+    typedef typename decay<decltype(true ? declval<_Tp>() : declval<_Up>())>::type type;
 };
----------------
Is it possible to make the non-variadic version SFINAE friendly as well? Or does it  require expression SFINAE (which ilslikely not available)?

http://reviews.llvm.org/D6964

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






More information about the cfe-commits mailing list