On Wed, Oct 3, 2012 at 4:41 PM, Matt Calabrese <rivorus@gmail.com> wrote:
On Wed, Oct 3, 2012 at 4:02 PM, Lorenzo Caminiti <lorcaminiti@gmail.com>wrote:
Hello all,
I have a SFINAE question. The following correctly returns false for eq1<x>::value when x has no operator==
I encountered the same problem in GCC when developing Generic, only with constructor-style initialization at the time -- I thought it was just a compiler bug, but since Clang is doing it too, maybe it's not. What I assumed was happening was that since it's in an unevaluated context, the compiler realized it could get the sizeof the expression without needing to know anything about the type of the subexpression, so it [incorrectly] only did syntax checking on it. In other words, it short-circuits before doing substitution so SFINAE never rules it out.
I noticed that wrapping the bool{} in a decltype works*: #define REQUIRES_T_a_b_c(n, expr) \ struct BOOST_PP_CAT(requires, n) \ { \ T a; T b; T c; \ template< typename TX > static boost::yes_type check ( \ TX a, TX b, char(*)[sizeof \ (decltype(expr)) \ ] \ ); \ template< typename TX > static boost::no_type check ( ... ); \ static const bool value = sizeof(boost::yes_type) == \ sizeof check<T>(a, b, 0); \ }; template< typename T > struct EqualityComparable { REQUIRES_T_a_b_c(0, bool{a == b}) REQUIRES_T_a_b_c(1, bool{a != b}) static const bool value = requires0::value && requires1::value; }; But I still would like to understand why it doesn't work without the decltype... (*) I'm just playing around now with some example so "works" has a very limited meaning at the moment. This way, I should be able to handle expressions... for types, I'm thinking require a typename prefix in the concept declaration syntax so I know not to use the decltype() in the code expanded by the macros: CONTRACT_CONCEPT( concept (Common) ( typename T, typename U ) ( requires( typename (CommonType<T, U>) // typename so I know this is a type and not an expression and expanded code won't use decltype ) ) )
However, I'm testing it now when not inside of a place where SFINAE may occur (though still with template arguments), and I correctly get an error when the template is instantiated. This is true with both GCC and Clang, so it seems like this unintuitive behavior may, in fact, be standard. I don't have time to check it out right now, but if someone references the standard and still can't figure out why you're getting this behavior, you could always submit a bug report to Clang. They're versed enough in standardese to determine if it's standard behavior or not.
I'd say that you could use a workaround, but I assume you want the {} syntax so that you could do the N3351 syntax for expression validation directly.
Also, I'm going to warn you now because I went down this same exact path with Generic -- you're going to have to change your approach for representing givens -- datamembers and even function parameters will not work. The problem is, you need to account for checking of "void", but with this implementation, you'll get a hard error instead of a compile-time bool value. You need to get everything into a context where SFINAE can take place. My approach with the old-style generic was to do all of the checking in a template specialization pattern list (as opposed to in a function template definition), and I used template reference parameters for the givens.
Yep, I'm not sure about data/function members... I'll definitely look at Boost.Generic source! Thanks, --Lorenzo