I can't review the whole library. So I'm confining my observations to just a couple of aspects. My method is to review some section of the documentation. it looks like a critique of the documentation, but it's really observations on the underlying design of the library. In this post I'm addressing Searchable in the reference section of the documentation. Searchable
From the explanation of Type class - given a type T, I'm expecting to see some sort of list of operations such that
Searchable<T> will compile.
What I see is:
boost::hana::Searchable Struct Reference
Type classes
Description
Data structures that can be searched.
Searchables have a concept of keys and values. Searching is always done on
the keys and the result is always the associated value. There is no
requirement that the keys and values be different.
Synopsis of methods
constexpr auto any
Return whether any key of the structure satisfies the predicate. More...
…
Instances and minimal complete definitions
struct instance< Map >
A map can be searched by its keys with a predicate yielding a boolean
Integral. More...
struct instance< Maybe >
Instance of Searchable for Maybes. More...
struct instance< Set >
The keys and the values of a Set are its elements; the Searchable
instance follows naturally from that. More...
My first thought is:
Searchable is (sort of) a C++ Concept (type constraints)
"Synopsis of methods" is what we customarily refer to as "valid expressions"
"Instances and minimal complete definitions" is what we customarily refer to
as "models"
But right away I have a problem - since "any" doesn't show a valid C++
expression at this level of the documentation I click "auto" and get:
Initial value:
= [](auto predicate, auto searchable) {
return Searchable::instance<
datatype_t));
}
// example
auto constexpr odd = [](auto x) {
return x % 2 != 0;
};
?::list<1, 2, 3> l;
static_assert( any(list, odd) ); // should not trap
?::list<2, 4, 6> l2;
static_assert( any(list, odd) ); // should trap with error at compile time
There are lots of "holes" in my example above, I think this more or less
captures
what you have in mind. But it's much simpler to understand and use.
I confess I've failed to understand the runtime aspects of your library.
This is
true even though I have worked with fusion more than most and a lot with
MPL. I
think this should be easy for me - but it's not.
BTW - I only used "Searchable" as it happened to be the first one I looked
at.
Personally I don't believe that thinks like "Searchable", and "Sortable"
don't
belong as models of type constraints. Using "Sortable as a quick example,
my complaint is that it's tautological. Something is defined here as
"Sortable"
if you can sort it. Actually something like "Sortable should be defined as:
template<class Iterator>
void quicksort(Iterator begin, Iterator end){
BOOST_CONCEPT_ASSERT((RandomAccessIterator<Iterator>));
BOOST_CONCEPT_ASSERT((LessThanComparable
Robert Ramey
I can't review the whole library. So I'm confining my observations to just a couple of aspects. My method is to review some section of the documentation. it looks like a critique of the documentation, but it's really observations on the underlying design of the library.
[...]
Based on your criticism, it seems to me that you do not understand important parts of the library; that's my fault for not documenting them or for doing it badly. I could write a long reply explaining rationales to some of your comments and explaining things on which you are downright wrong (e.g. did you really read the documentation for BOOST_HANA_STATIC_ASSERT[1]?), but I'd rather spend that time improving the documentation so everyone can benefit. I made the mistake of thinking Hana was well documented enough before it was. That's my mistake. Now, I'd ask from you that you wait until I have improved the documentation and clarified some common misconceptions (which I did not think would be problematic) before going forward with your review of the library. Doing otherwise would be losing your time and making me lose mine in writing replies like this one. Regards, Louis [1]: http://ldionne.github.io/hana/group__group- details.html#gab7f4d2cdacf9c644755995da69af8d4f
participants (2)
-
Louis Dionne
-
Robert Ramey