On Tue, 7 Nov 2023, 13:52 Matthew Taylor via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> Forgive me if I missed something obvious, but I'm not sure I see the
> motivation behind this proposal.
>

Mundane things like "motivation" and "more than a few hours of usage
experience" are not how Frederick rolls.


std::async will always be a possibly exception-prone function because there
> simply is no way to guarantee that the system will have the resources
> available to start a thread (if required) or allocate a shared state. While
> I'm no expert on the internal workings of the concurrency library, I'm not
> sure your proposed implementation is exception free either - the act of
> creating a shared state for your default-return-value promise/future
> pairing may be dynamically allocated and so may throw std::bad_alloc. In
> any case, should async fail due to some system or implementation issue, I'd
> argue that it's better to fail immediately and loudly.
>
> Consider someone using this code. They call async_noexcept, get a future,
> and since nothing goes wrong they reasonably assume that the result of
> their call will be available in that future in due course. They may then go
> on to do X, Y, and Z and get to the other end of the program before calling
> get() on the future and only then learning that their initial async failed
> and they did all this extra work for nothing. Would your proposal mandate
> that as basic error handling, a user is also expected to do some
> investigation of their obtained future and try to deduce whether it failed
> without opening it up to try and get() it?
>
> I'm not a big fan of just swallowing every possible exception either, or
> mandating that the user provide some meaningless default value for the
> error case - that pattern has never worked for everyone and one of the
> benefits of std::optional is that we don't have to do it any more. But that
> aside - what's the benefit of this proposal to outweigh the additional
> boilerplate it pushes onto the user?
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>