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

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-08-14 11:45:55

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.

This is exactly how I got to where I am now.  When I wrote the
serialization library, I could see users plugging in invalid type
parameters and getting back a raft of useless error messages.
So, one by one, I inserted static asserts to trap all this.  I couldn't
emit my own error message, so this code is riddled with 
"If your compiler emits an error here, ..."
I even created BOOST_STATIC_WARNING to trap situations
which though legal - were highly suspect.  legal suspects if
you will.

Then I needed to get the documentation done. I just couldn't
get it right.  I couldn't figure out how to describe the T 
in

template<class T>
f(...)

where T wasn't a particular type.   My attempts to document
the serialization library without this knowledge led to
a long discussion on this subject. During the whole time 
I never figured this out.  Since I'm a smart, stubborn guy that didn't
really understand the idea - and David Abrahams was involved,
you can imagine that it was a pretty circular, pointless and 
contentious discussion. 

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 had looked at Boost Concept library and the stl documentation and
it made no sense to me. Sometime after the discussion referred
to above I figured all this out. I always felt that I was
mislead by the pesky word "concept".  So my argument that
it be dropped in favor of "type requirements" or 
"type constraints" is not theoretical - it's motivated
by pure pragmatism.

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

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

> someone should really write a book on that topic actually.

lol - I hope not.  OK - I'll write the world's shorted C++
programming book.

Template Type Requiements
by Robert Ramey

All template type requirements need to be defined -
otherwise how can they be implemented?

Hence, these definitions need to be documented -
otherwise how can users know what they are?

Hence, they need to be enforced, because users
won't read the documentation until they get an error.

Robert Ramey

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