Re: [boost] [GSoC] [Boost.Hana] Formal review request

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Roland Bock (rbock_at_[hidden])
Date: 2014-08-03 12:09:59

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<typename Context, typename T, typename Enable = void>
>     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<class Context, class T>
>         auto requires_(Context ctx, const T& x) -> decltype(
>             has_type<typename Context::T, T>(),
>             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