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

Subject: Re: [boost] [Hana] Migrating sqlpp11 to Hana (hypothetically)
From: Roland Bock (rbock_at_[hidden])
Date: 2015-06-16 16:25:45

On 2015-06-16 16:09, Louis Dionne wrote:
> 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.
I do hope that libraries like Hana, Metaparse and sqlpp11 help in
proving that there is need to add language support for compile time strings.

>> [...]
>>
>>>> _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?
Got it, thanks!

I'll try to do some more testing before the end of the review (but I am
a bit swamped right now).

Regards,

Roland