I don't care whether you think me is a bot or not. I don't care how you treat me. The only thing you concern is bot, you don't concern about creativity.
I think you are a bot actually because you could only blame others into bot and I have never seen your valuable discussion.

I have developed semantic in cpp, java and typeacript.
Now I have semantic family:

  *
- cpp version£ºhttps://github.com/eloyhere/semantic-cpp
  *
- typescript version£ºhttps://github.com/eloyhere/semantic-typescript
  *
Java version£ºhttps://github.com/eloyhere/semantic-java

I don't think you could write a masterpiece with three coding languages.
You are a bot actually.
I don't want to care about your reply.
»ñÈ¡Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Alejandro Colomar via Std-Proposals <std-proposals_at_[hidden]>
Sent: Sunday, January 4, 2026 7:37:52 AM
To: Jens Maurer via Std-Proposals <std-proposals_at_[hidden]>
Cc: Alejandro Colomar <une+cxx_std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Labelled parameters

Hi Jens,

On Sun, Jan 04, 2026 at 12:19:12AM +0100, Jens Maurer via Std-Proposals wrote:
>
> 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++.

Kim Eloy is an LLM bot (or something like that). I'd suggest ignoring
it entirely.


Have a lovely night!
Alex

>
> 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.
> >
> >
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
<https://www.alejandro-colomar.es>