Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-08-15 17:21:03
On August 15, 2014 12:57:48 PM EDT, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
>On 14 Aug 2014 at 8:45, Robert Ramey wrote:
>> Niall Douglas wrote
>> > Anyway, if I feel that bad template parameters would generate
>> > unhelpful error messages, I'll usually throw in some sort of
>> > clarifying static_assert like the above. I view these as very
>> > to C-style asserts - there to be useful during development, not as
>> > parameter constraints.
>> Eventually the penny dropped and I got the documentation
>> fixed up. I never did go back and change the static asserts.
>> They're not wrong - but having them directly relatable to
>> the explicit concepts in the documentation would have made
>> them less ad hoc. Also, it would have made explicit a bunch
>> of underlying assumptions in the code. It would have made
>> me see that I had several similar ideas which could have
>> been consolidated. In short it would have given me a framework
>> for making simple, more understandable and less incorrect
>> code and avoided some asymmetries which haunt the code
>> to this day. Maintaining backward archive capability would
>> mean a lot more work to make these changes today.
>I think this is the crux of our difference. You believe that type
>constraints are a good thing, and that structures of constrained type
>relations build meaning and enables better communication in
>I on the other hand believe that type constraints pre-Concepts-Lite
>are a bad thing, and I wish the compiler wasn't so stupid - moreover,
>I know the compiler soon won't be so stupid. I see them as input
>sanitisers as a necessary evil, and they at best might be
>occasionally useful but generally they just get in the way and make
>code brittle both now and in the future. Hence they get used as
>sparingly as possible in assertion checks. I obviously use them
>extensively in metaprogramming, but that's constraining /selection/
>of implementation which is opposite to sanitising inputs.
Setting aside your bias against type constraints, explain how a static_assert* in a class or function template, to ensure the parameterizing type meets the syntactic requirements, is a bad thing. Using them prevents template backtrace spew from the compiler which I see as good.
*Boost.Concept Checking Library is just a fancy version of static_assert.
(Sent from my portable computation engine)