Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Eric Niebler (eniebler_at_[hidden])
Date: 2015-03-11 02:42:29

On 3/10/2015 4:31 PM, Louis Dionne wrote:
> Zach Laine <whatwasthataddress <at> gmail.com> writes:
> 
>>
>> On Sun, Mar 8, 2015 at 2:56 PM, Eric Niebler <eniebler <at> boost.org> wrote:
>>
>> [...]
>>
>>> As for lazy branches, that can also be handled simply by let/defer:
>>>
>>> // Test that the unselected branch does not get evaluated:
>>> template<typename T>
>>> using test_lazy_if_ =
>>>    let<lazy::if_<std::is_void<T>, T, defer<std::pair, T> > >;
>>> static_assert(std::is_same<test_lazy_if_≤void>, void>::value, "");
>>>
>>
>> And don't forget this part! :)
> 
> Oops, I forgot. Ok, so lazy branches in Hana work as follows. First, you
> use the `eval_if` function, which takes a condition and two branches in 
> the form of lambdas. But that's not all; the lambdas must accept a parameter
> (usually called _), which can be used to defer the compile-time evaluation
> of expressions as required. An example:
> 
>     template <typename N>
>     auto fact(N n) {
>         return hana::eval_if(n == hana::int_<0>,
>             [](auto _) { return hana::int_<1>; },
>             [=](auto _) { return n * fact(_(n) - hana::int_<1>); }
>         );
>     }
> 
> What happens here is that `eval_if` will pass an identity function to
> the selected branch. Hence, `_(x)` is always the same as `x`, but the
> compiler can't tell until the lambda has been called! Hence, the compiler
> has to wait before it instantiates the body of the lambda and no infinite 
> recursion happens. 

The identity function hack is a little unfortunate, but I understand the
need for it.

What if the two branches return different types? It seems like it
/should/ work when passed a runtime int like 11, as well as when passed
a compile-time integral constant wrapper like
std::integral_constant<int,11>. Is that how it works? That would be nifty.

For reference, with Meta:

template<typename N>
struct fact
  : let<lazy::if_c<(N::value > 0),
                   lazy::multiplies<N, defer<fact, dec<N>>>,
                   meta::size_t<1>>>
{};

Obviously only a compile-time computation.

<snip>
> Also, there are several caveats. First, because we're using lambdas,
> it means that the function's result can't be used in a constant 
> expression.

:-(

> The second caveat is that compilers currently have several bugs
> regarding deeply nested lambdas with captures.

Meh. Bugs can be fixed.

> Finally, it means that conditionals can't be written directly inside
> unevaluated contexts.

:-(

<snip>

Using lambdas for lazy conditionals brings limitations and pitfalls.
Would you consider adding a pure type-level alternative for people doing
straight metaprogramming?

-- 
Eric Niebler
Boost.org
http://www.boost.org