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-F... Sent from the Boost - Dev mailing list archive at Nabble.com.