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]socpp.org>
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.