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
>>> > 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:
> 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 :
> namespace detail
> <typename... T>
> struct wrong
> using type = std::false_type;
> <typename... T>
> using wrong_t = typename detail::wrong
> 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  template
> Context, typename T>
> struct serializer_t
> "missing serializer specialization");
> // Any number of valid specializations like this 
> <typename Context, typename... Args>
> struct serializer_t<Context, column_t<Args...>>
> // You could have static asserts here, too
> // Or you can switch off certain cases :
> template<typename Lhs, typename Rhs, typename On>
> struct serializer_t<sqlite3::serializer_t, join_t<outer_join_t, Lhs,
> Rhs, On>>
> ::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.
> : https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/wrong.h
> : https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/column.h
> Unsubscribe & other changes:
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
with this information. You an either post a comment or send it directly to
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
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
a small group who spend years disputing how to implement the idea.
Let's start making things better right now!
-- 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