Boost logo

Boost :

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>> writes:
>> On Sun, Mar 8, 2015 at 2:56 PM, Eric Niebler <eniebler <at>> 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>>>,

Obviously only a compile-time computation.

> 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.



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 list run by bdawes at, gregod at, cpdaniel at, john at