
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