Hi,

I don't understand exactly the context where this could be needed.

If this is needed for std::promise also, have been there some posts in std-discussions or std--proposals ML or elsewhere for such a proposal?

It is weird that Gor has not raised the issue already. IIUC, currently the adaptor can store it already. How the proposed feature would improve the performances?

The C++ principle is to don't pay for what you don't use. I believe that the adaptor solution is the good one. Maybe the adaptor would need to store an expected and promise should provide a setting from an expected (but we don't have expected neither on Boost nor the standard). I would like to see a std-proposal discussion so that people that know well the standard thread library can tell what they think.

If the feature was really needed:

    What will be the possible interactions of the deferred settings/notifications and the normal settings? I hope you expect UB if you mix them.
    Does notify_deferred requires that there should had already a call to set_value_deferred/set_exception_deferred?
    What would be the expected interactions between two calls to set_value_deferred/set_exception_deferred? UB?
    What will be the impact on normal futures performances? Does the implementation needs additional flags that must be checked?

You can create a github issue to track this possible enhancement.