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

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 
documentation.

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 
documentation.

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/