Re: [boost] RFC Expression Validity Asserts

Subject: Re: [boost] RFC Expression Validity Asserts
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2015-01-22 21:11:17

On Thu, Jan 22, 2015 at 5:24 PM, TONGARI J <tongari95_at_[hidden]> wrote:

> 2015-01-23 8:26 GMT+08:00 Matt Calabrese <rivorus_at_[hidden]>:
>
> > On Thu, Jan 22, 2015 at 4:12 PM, Matt Calabrese <rivorus_at_[hidden]>
> wrote:
> >
> > > On Thu, Jan 22, 2015 at 4:09 PM, Matt Calabrese <rivorus_at_[hidden]>
> > wrote:
> > >
> > >> For instance, you can use it to easily do:
> > >>
> > >> template <class T>
> > >> struct has_preincrement_operator
> > >>     : std::integral_constant<bool, IS_VALID_EXPR((T) a, ++a)> {};
> > >>
> > >>
> > >
> > Hmm, actually this use doesn't seem to work, though I'm not sure why... I
> > should have tested it in the browser before posting the sample. I'm
> pretty
> > sure it fails due to a compile-bug but I'm not entirely certain.
> >
>
> I'm sure that lambda cannot be used in unevaluated context.

Right, but the magic of this trick is that it's not actually using the
lambda in an unevaluated context (at least that's my understanding, and
I've searched the standard for all instances of the term unevaluated)! A
lambda itself never actually appears in a
typeid/decltype/sizeof/alignof/noexcept. I do the tricks indirectly, using
the lambdas just as a means to introduce declarations inside a nested scope
of the expression and to create nested templates via generic lambdas for
SFINAE. No lambda itself is actually invoked or directly used in an
unevaluated context. I deduce information that the lambdas contain
indirectly.

Anyway, what is interesting is that the following *does* compile, as I
thought it would:

//////////
using T = std::integral_constant<bool, IS_VALID_EXPR((int) a, ++a)>;
//////////

The above uses the lambda internally in the same way as the previous email,
but without failure. I just pass the result of the macro invocation as a
compile-time bool template argument, with the main difference being that I
use "int" here instead of a dependent type. I don't immediately see why
that difference should cause failure. As far as I can tell, they should
both compile, or if I'm wrong somewhere, it seems that NEITHER should
compile.

-- 
-Matt Calabrese