Hi Louis,
First of all: Hats off to you, your library and the documentation!
I wanted to play with Hana for quite some time now. The review certainly
offers a good reason to do so :-)
Here's my test project: In sqlpp11 [1], lets assume I wanted to replace
my own implementations of
* compile time strings
* type sets
* functions like any/all/none
with something from Hana.
_Compile__time strings:_
This one seems easy. There probably won't be a C++14 version of sqlpp11,
but there will be a C++17 version, hopefully allowing me to use the
string literal without relying on a non-standard compiler extension.
This is what I currently have [2]:
struct _alias_t
{
static constexpr const char _literal[] = "delta";
using _name_t = sqlpp::make_char_sequence;
};
This is what I would like to do:
struct _alias_t
{
using _name_t = decltype("delta"_s);
};
But the whole thing is in a header.
* I do not want to "using namespace ::boost::hana::literals" at
top-level or in one of the namespaces in the header.
* Neither one of the following lines is valid:
o using _name_t = decltype(::boost::hana::operator"_s"("delta"));
o using _name_t =
decltype("delta"::boost::hana::literals::operator"_s");
o using _name_t =
decltype("delta"::boost::hana::literals::operator""_s);
Is there a valid version? Obviously, I would also be happy with
something like
using _name_t = decltype(ct_string("delta"));
* I also cannot use the BOOST_HANA_STRING macro, btw, because that
would be a lambda in a decltype...
I want to gradually migrate to Hana, so I'd really like to use a type
here, not a variable. But I could not even use a variable, because the
following does not compile (clang-3.5.1)
struct A
{
static constexpr auto hana_name = BOOST_HANA_STRING("cheesecake");
};
Any hints?
_
_
_type sets:_
Currently I store a bunch of types in type sets to do all kinds of tests
at compile time. My type set code will need some cleanup or replacement
one fine day. Hana to the rescue...
Er, wait a second. There is no type set, or is there? There is a set for
objects (which might represent types). Replacing all those types with
objects would take some time, but I could live with that, I guess. But
then I would have to replace all my type_sets (which are types
themselves) with static constexpr objects, which use tons of constexpr
template variables. And there are other constructs which use the types I
now have replaced with objects. So I would have to adjust them, too,
probably turning even more types into objects. Can I be sure (given
today's compilers) that all these objects stay away from the generated
binary?
Also, I did not find some of the methods I would expect for sets:
* Create a joined set
* Create an intersect set
* Create a difference set
* Test if two sets are disjunct
* Test if A is a subset of B, no, strike that, just found it in Searchable
I probably could create the methods above with just a few lines of code
using the available functions. But it would be convenient to have them
available, of course (or did I just miss them?).
By the way, I guess it would be easy for you to compile a list of
available methods for each type, e.g. Set. Such a mini-index would be
quite helpful IMO.
_any/all/none:
_Quite a bit of code is tuned to stuff like std::is_same: a type that
contains a value (true or false). My current versions of any/all/none
work like that, too.
If I wanted to get rid of my own versions, could I use a drop-in from
hana? Or would I have to write something like
template
struct my_all
{
static constexpr bool value =
::boost::hana::all(::boost::hana::make_tuple(B...));
};
?
_Intermediate summary:_
* I am not sure if I could replace my current compile-time string yet
* I would like to have a few more convenience methods for Set.
* It seems to me like if I wanted to use Hana, I should switch to
Hana-style completely. Otherwise it will just be a weird mixture.
Best,
Roland
[1]: https://github.com/rbock/sqlpp11
[2]: https://github.com/rbock/sqlpp11/blob/master/tests/Sample.h#L14-L17
