Re: [boost] [next gen future-promise] What to call themonadicreturn type?

Subject: Re: [boost] [next gen future-promise] What to call themonadicreturn type?
From: Avi Kivity (avi_at_[hidden])
Date: 2015-05-26 06:35:15

On 05/26/2015 12:20 PM, Niall Douglas wrote:
>>> The constexpr folding has the compiler elide all that.
>> I suspect that what you call "constexpr folding" has nothing to do with
>> constexpr, it's just inlining and ordinary non-constexpr optimization. KAI
>> C++ was famous for doing such folding miracles decades ago.
> You're right it's not in the standard. Well, actually it is, but
> indirectly.
>
> Let me explain. If you read what is allowed for constexpr at
> http://en.cppreference.com/w/cpp/language/constexpr, and then write
> logic which provides outcome paths which do nothing not constexpr,
> then the compiler will completely elide code entirely at compile time
> when those paths are followed. If you examine my code closely, you'll
> see I always predicate the construction of anything with a
> non-trivial destructor (e.g. exception_ptr) because non-trivial
> destructors appear to force code output in current compiler
> technology, though it may also be the atomic writes that
> exception_ptr does.
>
> This probably is not by accident. The machinery inside the compiler
> to implement constexpr is probably reused for optimisation, or
> rather, vice versa. Maybe a compiler vendor might chime in here to
> tell us?

I believe it is an accident.  While the compiler is required to fold a 
constexpr expression in a constexpr context (like an array dimension or 
non-type template argument), it isn't required to do so in non-constexpr 
contexts, and won't do so if optimization is not enabled or if it makes 
a bad inlining decision (say, because the function was too large).

The optimization machinery for folding constants is actually a superset 
of constexpr, and as a result you will sometimes get a constexpr 
expression not optimized, and sometimes a non-constexpr expression will 
be folded to nothing.

>
>>> Also if you call promise.set_value() before promise.get_future(), you
>>> never get synchronisation as futures are single shot.
>> Another interesting case for which I've trouble imagining a practical use.
>> :-)
> Its main benefit for me is as a unit test smoke test. However
> resumable functions, as currently proposed, should hugely benefit
> from this pattern. I've emailed Gor about it.
>

I am also waiting for resumables (and concepts, and modules, and 
ranges...) with bated breath.