On 2014-08-03 15:37, pfultz2 wrote:
b) You have one or more full or partial class specializations for specific classes/templates/values:
Basically as above, but if you want to prohibited the default case or certain specializations, here's a nice, minimalistic helper to do so This is a perfect example of when *not* to use static_assert. You should leave the class undefined:
template
struct serializer_t; Then the compiler will already give a simple and informative error about the class being undefined, which is almost the same error you put in the static_assert. I don't see it that way because
*) even though I as a library author /might/ be able to interpret the compiler message in the same way (and I admit, I am not), a user has no way of knowing what's going on. Is there an include missing which might contain the definition of the struct? Is it a library error? Or am I using the library in a way that I should not? The static assert on the other hand sends a clear message, that can even be documented (whereas compiler messages will change from version to version). *) the Enable parameter is an artifact, a trick and yes, I know it and I use it, but it is really only there for technical reasons. If I can do without it, I will.
Futhermore, say I want to know if there is a valid serializer at compile-time and if not then choose a different method. So, I create a predicate to detect a valid serializer:
TICK_TRAIT(has_serializer) { template
auto requires_(Context ctx, const T& x) -> decltype( has_type (), Context::_(x, ctx) ); }; Unfortunately, this won't work because of the hard error, and it won't work with Concepts Lite either.
Right. static_assert does not mix with enable_if or similar stuff, since it is a hard error. In the case of sqlpp's serializer, it would not make much sense to check that. And if someone really, really wanted it, I could add a flag for him to check, since in reality, the static_assert happens in a method of the struct. I shortened the code a bit for the mailing list. But yes, that is a drawback of static_assert. BTW: When I start to use Concepts Lite, I expect at least 90% of the static asserts to go away. Most of them are just used because they are better than the current alternatives IMO.
`static_assert` can be used to check variants outside of type requirements, but in general, it should not be used for type requirements.
I'd say static_assert is not the golden hammer for type requirements, but it can be used in quite a few cases to enforce type requirements. Cheers, Roland