Boost logo

Boost :

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-08-15 12:57:48

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 similar
> > to C-style asserts - there to be useful during development, not as
> > parameter constraints.
> [snip]
> 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.

> So I've come to believe that it absolutely necessary that
> type requirements be explicitly defined. (Otherwise how
> could we define their enforcement.) So these requirements
> have to in the documentation. (Otherwise how is a user to
> know what they are? ). Again, I haven't specified and detailed
> form or any specific documentation tools, I'm limited my
> argument to saying that the type requirements on every
> template parameter must be documented and enforced
> if possible

I have no problem with implicitly defined, and are an informal
consensus. I do have an especial problem with their effect on

That said, I have never used your Serialisation library. Maybe if I
do one day I may realise that concepts or type constraints have
nothing to do with good or bad documentation, and my negative
association is merely an artefact of random chance.

> > It is odd how profound philosophical
> > disagreement can have such little real effect on code written -
> Really, I don't see it as a philosophical or theoretical issue
> but rather a purely pragmatic one. My views and arguments
> are motivated by real experience which I hope to spare
> future library authors. (and users).

I would say exactly the same about my own.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at