beman.execution26: change library status to under development

[RaduNichita]

Issues: bemanproject/beman#77

Expected README.md:

[neatudarius]

I agree the API is stable (it's in the Draft). I ask @dietmarkuehl to confirm if the library is also production ready.

Thanks!

CC: @bemanproject/leads

[dietmarkuehl]

I'm not convinced that is the correct status: there are few bits missing from P2300 which still need to be implemented. There are also a number of things tagged "TODO" in the code which should be addressed in some form.

[neatudarius]

Ok, this is why we explicitly asked you. What do you recommend? (Please check BEMAN_LIBRARY_MATURITY_MODEL.md)

[dietmarkuehl]

Looking at the Beman Library Maturity Model the implementation is "under development": while the API is approved and merged into the working paper, the implementation isn't complete covering all of the API. Also, the API isn't standardised, yet, an possibly subject to change.

One interesting side question is: the repo currently contains [partial] implementations of multiple papers:

• std::execution which is merged into the standard.
• async_scope -- Creating scopes for non-sequential concurrency which is moving towards getting merged soon.
• C++ Concurrent Queues which is under discussion and may get merged soon.

There are also a few additional papers in the space which fit the theme of this project:

• finally, write_env, and unstoppable Sender Adaptors.
• let_with_async_scope.
• Allocator Support for Operation States, already implemented.
• Enabling more efficient stop-token based cancellation of senders, partially implemented, although rejected. I think some of that could be salvaged when opting into use of a constrained stop token.
• Reducing operation-state sizes for subobject child operations.
• there are possibly more

For some of these proposal it doesn't make any sense to got into a separate Beman project as the inherently change how things are implemented. Others are add-ons which may get into the same header. Creating them in a separate Beman project would, at minimum require some approach to reconcile how they are used. Some are just add-ons and could get into a separate Beman project requiring separate infrastructure and creating a more awkward user experience. Which raises a few questions:

1. Should things be factored into different Beman projects if it is possible?
2. For things within one project, the proposals may be in different state for readiness: should they have separate maturity indicators?

I guess, that may be a discussion for Discourse and I'll post the question there.

[dietmarkuehl]

The status needs to be adjusted: the library is currently still under development