You must be logged in to post a comment.
I'm looking at traits.h line 208 "is_weakly_ordered"
a) I seems there is no difference between is_weakly_ordered and is_totally_ordered
I'm thinking that is_weakly_ordered should be:
static auto req_impl(T&& x) -> valid<
TICK_RETURNS(x < x, bool),
TICK_RETURNS(x > x, bool)
This would seem to be more consistent with https://en.wikipedia.org/wiki/Weak_ordering
and https://www.sgi.com/tech/stl/StrictWeakOrdering.html .
b) if the above is correct, making the change would is_weakly_ordered the same as is_less_than_comparable
c) the documentation should contain a reference section so that one doesn't have to sift through the source code to find the set of traits already defined.
I’ve only taken a very cursory look at this but it looks VERY interesting to me.
As is well known, I’ve become a strong advocate of the usage of type requirements in library code. see http://blincubator.com/advice_concepts/
This looks to me to be a library implementation of something similar to “Concepts Lite” or Boost Concept Checking library. I would like to see in the documentation how this library compares to those two alternatives. Also, I would like to see the name/nomenclature used in the library to be more compatible with other alternatives. I imagine that other users might read this documentation and not make any connection between this and the alternatives mentioned. I would also like to see a number of more complete examples showing users how to use this to make their library code more robust and catch more errors at compile time. I wrote a really simple explanation for this in my advice section and I would like to see something similar here. For related thoughts on this see my talk at CPP Cone https://www.youtube.com/watch?v=ACeNgqBKL7E
Putting another way – “marketing” of this library would be much more effective if it leveraged on things that people have already been exposed to.
> Also, I would like to see the name/nomenclature used in the library to be more compatible with other alternatives.
I am not sure what you are fully referring to here, but I know people have brought up the name of the library in the past. I am thinking about changing the name to Boost.ConceptTraits which seems a better name for the library, but I am not sure the best time to do that, perhaps after a formal review?
Also, are there other names used in the library that seem incompatible to the other alternatives?
I think there is/was a library named Concept Traits – maybe it would be interesting to look at. https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.ConceptTraits
The best way to get it to formal review is to get people to use your library. And the best way to do that is to make it easy to understand what it does, and how it can helpful. BCC hasn’t been touched in quite a while so there is likely opportunity here.
Note that I’ve been making a big effort got make “Parameter Type Constraints” a requirement for boost libraries. Seems like your effort might dovetail with that. Note that my comments are just from a cursory examination of the documentation. But this needs to be expanded to make your library easy to use for “the rest of us” including me.