
On 14 Aug 2014 at 8:45, Robert Ramey 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
Niall Douglas wrote 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/