[Proposal] JavaScript-style Promise as a layer over senders/receivers
Thank you for your guidance and for pointing me to the correct direction regarding senders and receivers. I do apologise for having posted to the incorrect thread; that was an oversight on my part. I shall create a new thread as suggested to discuss this matter properly.
Having now properly reviewed the senders and receivers framework as outlined in P2300, I can see the considerable thought and elegance that has gone into its design. My proposal for a Promise-style abstraction is very much intended to sit as a higher-level convenience layer atop this foundation, rather than propose an alternative direction. The intention is to provide a gentler onboarding experience for developers arriving from languages where Promise-based asynchronous programming is the norm, whilst fully respecting the power and composability of the underlying sender/receiver model.
In practical terms, the concept would be to offer a Promise type that is constructible from any sender, and is itself convertible back to a sender. This would allow developers to use the familiar 'then' and 'except' chaining for straightforward cases, whilst seamlessly interoperating with the richer compositional model of senders and receivers when more advanced patterns are required. The goal is to lower the initial barrier without creating a separate ecosystem, ensuring all such code remains fully compatible with the standard asynchronous execution framework.
I should be most grateful for the committee's guidance on whether such a complementary abstraction would be considered valuable. If there is interest, I am very willing to refactor my implementation to align precisely with P2300 and to contribute to any relevant ongoing work. I would also appreciate any advice on which existing proposal or study group might be the most appropriate forum for further discussion. Thank you again for your constructive feedback.


»ñÈ¡Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Jens Maurer <jens.maurer_at_[hidden]>
Sent: Sunday, January 4, 2026 7:19:12 AM
To: std-proposals_at_[hidden]ocpp.org <std-proposals_at_[hidden]>
Cc: Kim Eloy <eloy.kim_at_[hidden]>
Subject: Re: [std-proposals] Labelled parameters


How is this related to "labelled parameters", which is the subject
of this thread?

If it is not, please make a new thread.
And explain how your approach meshes with senders/receivers,
the selected asynchronous execution framework for C++.

Jens


On 1/4/26 00:15, Kim Eloy via Std-Proposals wrote:
> I have introduced the Promise designed by JavaScript to cpp.
> And you can use like this in cpp:
> Promise<int> p = threadPool.submit(...);
> p.then([](int x)->{
> std::cout << x;
> });
> p.except([](exception e)-> void{
>
> });
> I have removed std:: future from my masterpiece because I think std::future is too complex.
> https://github.com/eloyhere/semantic-cpp
> I am devoting to make cpp development more relaxing!
>
> »ñÈ¡Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jan Schultke via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Saturday, January 3, 2026 5:24:55 PM
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* Jan Schultke <janschultke_at_[hidden]>
> *Subject:* Re: [std-proposals] Labelled parameters
>
>
> When reading your work-in-progress proposal, I immediately noticed this problem about existing standard library functions. I¡¯m not sure if it is feasible for the standard to prescribe argument names. They¡¯d have to be collision-free with macros which means we can only get ugly names.
>
>
> If you create macros like x and y, you get what you deserve. Any reasonable library will define their macros like MY_LIB_X to avoid these issues.
>
> Wouldn¡¯t it make sense to allow some form of annotation for named arguments?
> void foo(int __x [[name=x]]);
>
>
> Notice that this still doesn't solve the issue of a macro "x" expanding to anything because that would break your attribute. If the goal is for the user to write ".x" anyway (which are two tokens), that call site is broken by macros anyway. I think it's best not to worry about this macro nonsense. If we actually cared about it, we would never be allowed to add new names to the standard library (for functions, global variables, enumerators, or anything else) because it may break user macros.
>
> On a more general note, myself and the other authors discussed the idea of requiring an explicit opt-in syntax, and polled it against it for a variety of reasons.
>
>