Re: [boost] [Hana] Migrating sqlpp11 to Hana (hypothetically)

Subject: Re: [boost] [Hana] Migrating sqlpp11 to Hana (hypothetically)
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-06-16 10:09:29

Roland Bock <rbock <at> eudoxos.de> writes:

>
> On 2015-06-15 21:08, Louis Dionne wrote:
> > Roland Bock <rbock <at> eudoxos.de> writes:
> >
> >> [...]
> >>
> >> _Compile__time strings:_
> >>
> >> [...]
> >>
> >>   * I do not want to "using namespace ::boost::hana::literals" at
> >>     top-level or in one of the namespaces in the header.
> > Is it acceptable to only import the `_s` string literal from Hana?
> >
> >     using boost::hana::literals::operator""_s;
> Not really. This code has to be provided by the user of the library. It
> lives outside the sqlpp namespace. I cannot just tell them, to please
> import some string literal into their namespace.
>
> [...]

I must admit I don't have a solution. This is such a pain since it is a
__joke__ in terms of implementation difficulty at the compiler/language
level, but I think it is not solvable at the library level.

> [...]
>
> >> _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<bool... B>
> >> struct my_all
> >> {
> >>    static constexpr bool value =
> >> ::boost::hana::all(::boost::hana::make_tuple(B...));
> >> };
> > The best way would be this:
> >
> >     hana::all(hana::tuple_c<bool, b...>)
> >
> > This would return a boolean IntegralConstant (which is convertible to
> > bool). This could also be made just as efficient as your clever
> > implementation using std::is_same (that you posted on the list a
> > while ago), because we have the knowledge that the content of the
> > tuple are compile-time bools. However, using
> > `hana::all(hana::make_tuple(b...))` will be comparatively
> > __very__ inefficient, because we can't know what's in the tuple
> > and we must guarantee proper short-circuiting.
> >
> Oh, because the it could be tuple_t<bool, Foo> and you still want this
> to work in case it short-circuits in the bool element?
>
> If so, that sounds quite strange to me.

Notice that I used `tuple_c<bool, b...>`, not `tuple_t<...>`. `tuple_c`
creates a Tuple containing IntegralConstants, in that case boolean
IntegralConstants. Using `tuple_c<bool, b...>` allows the representation
of the tuple to be optimized for some types of computations, like
`all()` & friends.

Using `all(tuple_t<...>)` does not make sense, because `tuple_t<...>`
creates a tuple containing types, but types do not have a logical value.

Does that make sense?

> [...]

Regards,
Louis