Boost logo

Boost :

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-08-03 11:48:56


Roland Bock-2 wrote
> On 2014-08-02 23:57, pfultz2 wrote:
>>> I would just like every library invoke a compile time assert whenever
>>> > in instantiate a template with type arguments which won't work.
>>> > Boost Concept Check can do this. In fact, maybe BCC is over kill.
>>> > I seriously considered recommending making concept checking classes
>>> with
>>> > just static_assert. But in the end I opted for recommending BCC.
>> Yes, of course, static assertions can help improve error messages and its
>> better than nothing, but it is not the same as template constraints.
> True, but static_assert covers the following cases at least and is
> really simple:
>
> a) You have one implementation (class or function) and arguments are
> either valid or not:
>
> template<...>
> struct X
> {
> static_assert(check1, "failed check1");
> ...
> };
>
> 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 [1]:
>
> namespace detail
> {
> template
> <typename... T>
> struct wrong
> {
> using type = std::false_type;
> };
> }
> template
> <typename... T>
> using wrong_t = typename detail::wrong
> <T...>
> ::type;
>
> It can be used to defer static_assert until a template is instantiated
> which is an error since it is prohibited:
>
>
> // disabled default case, slightly shortened from [2] template
> <typename
> Context, typename T>
> struct serializer_t
> {
> static_assert(wrong_t
> <serializer_t>
> ::value,
> "missing serializer specialization");
> };
>
> // Any number of valid specializations like this [3]
> template
> <typename Context, typename... Args>
> struct serializer_t&lt;Context, column_t&lt;Args...&gt;>
> {
> // You could have static asserts here, too
> };
>
> // Or you can switch off certain cases [4]:
> template&lt;typename Lhs, typename Rhs, typename On&gt;
> struct serializer_t&lt;sqlite3::serializer_t, join_t&lt;outer_join_t, Lhs,
> Rhs, On&gt;>
> {
> static_assert(::sqlpp::wrong_t
> <serializer_t>
> ::value, "No support for
> outer join");
> };
>
>
>
> static_assert is not sufficient for selecting overloads or if you have
> several class specializations and need to select the correct one based
> on concepts like ForwardIterator or so. In those cases, I would use
> enable_if or similar (and wait for Concepts Lite).
>
> In the sqlpp11 code, which enforces type constraints in pretty much
> every template, enable_if is required in only about 7% of the templates.
> Most of them are implementations of the constraint-checks.
>
> Regards,
>
> Roland
>
>
> [1]: https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/wrong.h
> [2]:
> https://github.com/rbock/sqlpp11/blob/develop/include/sqlpp11/serializer.h
> [3]: https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/column.h
> [4]:
> https://github.com/rbock/sqlpp11-connector-sqlite3/blob/develop/include/sqlpp11/sqlite3/serializer.h
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

I see using static_assert as a real practical method for many users.
But just saying one can use static_assert to implement type constraints is
not quite the
same as showing users how to do it. I would encourage you go to enhance
http://rrsd.com/blincubator.com/advice_concepts/
with this information. You an either post a comment or send it directly to
me.

My real goal is to convince the C++ community that any library which
includes templates as part of the user interface must have explicit type
constraints
in order to be considered for formal review. I want to see type constraints
be understood and appreciated by the C++ user community in general rather
than
a small group who spend years disputing how to implement the idea.

Let's start making things better right now!

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/Re-GSoC-Boost-Hana-Formal-review-request-tp4665622p4665972.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk