Roland Bock-2 wrote
On 2014-07-31 19:54, Robert Ramey wrote:
Eric Niebler-4 wrote
On 07/29/2014 05:14 PM, Niall Douglas wrote:
I'm all for Concepts as in compiler enforced ones, and I'll add them to AFIO when and only when C++ gets them. But for documentation they don't help. Wow, I couldn't disagree more. I can't imagine how the standard algorithms would be specified without the use of concepts like "RandomAccessIterator", for instance. Clustering requirements into meaningful abstractions and assigning them names makes it possible to document library interfaces without an explosion of verbosity and repetition. +10 +10
Can't wait till Concepts Lite are there!
Usage of concepts is greatly:
a) misunderstood b) misunderestimated as to their value in design AND documentation
Right, last year, I heard several people basically asking "why on earth would anyone want this?" after listening to a talk about Concepts Lite. It took me a about an hour at dinner to convince some of them that it might be worth looking into the topic a bit more...
d) The word "concepts" is a big contributor to the problem - substitute "type requirements" or "type constraints" for concepts.
I like "type constraints" best.
c) usage of concepts is much confused with implementation of concepts. Usage of "type constraints" doesn't require any special support from C++. static_assert with type traits is usually all that is necessary. e) recent papers using examples such as "Sortable" add more bad advice and confusion.
I've included a page in the Boost Incubator to promote my views on the subject - if anyone cares.
Very nice compilation!
I am impressed by Boost Concept Check Library (the second link to it is broken in your document, btw). But I feel rather helpless when stumbling over problems (for example, your code does not compile with the admittedly ancient boost 1.46 on my machine and I have no idea what to do with the compile errors).
I am therefore rather sticking with static_assert to enforce constraints with friendly error messages for the time being until Concepts Lite are available as TS or part of the standard.
I want to actively promote the usage of "template parameter type requirements" in Boost Library design. And I'm very interested in getting help on this. As a start, I'd be happy to receive suggestions for amendments / enhancements to the page on the incubator. http://rrsd.com/blincubator.com/advice_concepts . These suggestions / enhancements can be posted as comments to the page. In particular, I'm interested in the following: a) promoting the usage of the term "type parameter constraints" (or something similar over the very confusing term "concepts" b) settlement of "best practice in the real world" of implementation of this idea. I recommended Boost Concept Check. Which isn't bad for a start, but isn't perfect either. I ideally I would like to see this used where its a good fit and an alternative for cases where it isn't. c) perhaps a recommendation as to whether "type constraint classes" be used as members or base classes for checking. d) the promotion of the idea that type reference documentation look more like STL documentation and explicitly reference "type constraint" pages. I'm intrigued by the mention of enable_if. I would like to know how that might be used in this context. I'm also wondering if it would applicable in places where I've used BOOST_STATIC_WARNING which has been useful - but unreliable. Robert Ramey
Cheers,
Roland
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- View this message in context: http://boost.2283326.n4.nabble.com/Re-GSoC-Boost-Hana-Formal-review-request-... Sent from the Boost - Dev mailing list archive at Nabble.com.