While all of the three features you propose may be part of an overall vision and they may interop in some way, each of them is enough material for one proposal. The first thing you'll hear from the committee if they see your paper is that you should break it up into three papers.

• Feature I — Statement Expressions
• Feature II — Unevaluated Parameters
• Feature III — Continuation Passing

Statement Expressions in C++ has no clear way forward. This has huge overlap with Barry Revzin's "do expressions", so you should look into that.

Unevaluated Parameters would require compiler support, and it's not clear to me that we need this instead of lambdas, or syntax sugar that makes a "generator lambda" from an expression. If our lambda syntax was shorter, it's not clear to me that we would need this at all.

On Thu, 2 Jul 2026 at 14:44, Lorand Szollosi via Std-Proposals <std-proposals_at_[hidden]> wrote:

HI std-proposals WG21,

The bekow message didn’t go through due to me using @isocpp.org instead of @lists.isocpp.org in the address. Since then, been busy surviving (for a while literally - since 12.3.2026, now having the first proped medic report since y’day - but also related to negotiations which might or might not require me to remove EPAM - or a local office of it - from the discussion, so *consider that* before replying - not representing or represented by a group of a multi-billionaree valuation, when, 2 days after the recent changes in Hungary some ‘surely not’ police agents asked for my phone to make a call and then started to search my money, joined the search :J).

The dramatic context is, and me being aware fully, when we write such a proposal, standardisation or similar, each and every aspect of it is verified, reflected back and tested on - and, in this case, since it’s apparent that it’s not only used for coding, but also reasoning in C++, to express thoughts and ideas in regions of our world that are better verified before communicated; where problems are only or mostly/preferably brought to light with proposed solution, like in genetics where we discuss up to human(!) birth, sociometry where we consider the structure of the society (including in some territories gender and religious belief/explanatory research, of which some are banned in some specific countries and we must use alternatives or parallels in terms of location or wording), physics modeling and ABI comprehensiveness limits (whether we are quantum-ready or even above that), code security (where we took a hit from Rust & it’s acceptance in govt sector) et. al. - so it’s tested on actual persons. In this case, we went back to sending messqges via VHF and actual agents, simulated some banking perspectives, can’t say haven’t patented some (so that sufficient control is established and we won’t run into that many kinds of troubles later with ill-formed first-a-good ideas of applicatkon). Literally tested, to some extent, on sea, ground and air and when discussing with that little snake of a language but not falling for it :), rather checking how it can be used with WASM and completely distributed ABIs, wrote a Musical and a cartoon of it (technically speaking - when in Hungary - it’s an «AI test log», the AI being prepared mostly in Luxembourg in an office rented for the purpose, on French servers and discussed in the Netherlands - and being discussed with Swiss/UN side besides some local defense / defense consultant side discussions and checks). The list is preliminary.

That said, *officially speaking*, so that there’s inclusion from territories where legislation does not yet permit e.g. gender research examples, or countries where even reasoning about CRISPR/Cas9, SCNT and iPSC and how these historically evolved while we were constantly discussing the standard; or how it affects (or what it reflects from) banks not only via bond-equity hedge, but e.g. oil sector and global macro (and for the jokes on «coding» and «status 1» in C++ vs. medic IT, have a suitcase for my medic reports), so *officially speaking* these are «AI-generated test logs» of or for a standard proposal and an implementation that’s already there to test in a however hacky way. This is actually created that way, after immerse amount of AI hacking and fine-tuning with equipment and toolings you don’t expect to see around yourself everyday, with more architectures on a table sometimes than in a museum - and with a little capy bearing the weight of an e-book reader on a machine :J which I used as a child, when learned assembly before C++ took the hard work off the shoulders in some contexts, similarly to when we can use it for embedded (FPGA HLS) and, after this proposal, a bit more on the market / area of VLSI, for directed hypergraphs pf evaluation can express routings better (and, in this context, from telco we have experience, whether University or Communities/Boards)..

In short, we suggest picking up from where coroutines didn’t fully deliver (or could’ve delivered more, had we had statement expressions proposal included).

We suggest standardising monadic c++ and unevaluated contexts (that bring operator overoads, as it’s described / will have been described, depending on your access, in the CppMusical). These are as simple as a marker cpass<> for monadics and uneval<> for unevaluated and are «purely sytax changes», as many changes are explainable as such in c++’s order and progress; but it helps making the code cleaner and provides further error handling and safe(r) codes.

Furthermore, it’s only «AI-generated» until we find (or until legislation permits) the proper people to rewrite parts, eventually rewriting possibly the entire proposal - in fact, for that, not having some big name on it might actually help; but, if you need to have ‘a name’ on it, the related patenting in a particular sector is dedicated to M. Szollosi and testing systems based on this to keep track of what was promised to him the last time we talked (and that’s not a previous, but an actual ‘last’, in this world).

Examples available on github currently (considering duplicanting the effort on the Dutch equivalent for legislational diversity); codes and docs linked below.

Cheers,

lorro (Lorand SZOLLOSI / Lorand J SZOLLOSI)

Begin forwarded message:

From: Lorand Szollosi <szollosi.lorand_at_[hidden]>
Date: 30 March 2026 at 17:39:23 CEST
To: std-proposals_at_[hidden]
Cc: std-proposals_at_[hidden]
Subject: se uneval cpass proposal and hack implementation



From: cpp_at_[hidden], fsta2015_epam_bridge_at_[hidden], shipping_at_[hidden], szollosi_at_[hidden], lorro%hnc_at_[hidden], lorro_epam_bridge_at_[hidden], medic_at_[hidden], lorro_at_[hidden], szollosi.lorang_at_[hidden]. wg21_se_uneval_cpass_proposal_at_[hidden]

Sender: szollosi.lorand_at_[hidden]

Subject: se uneval cpass proposal and hack implementation

Date: Mon, 30 Mar 2026, 17:30:29 in Luxembourg

Dear std-proposals_at_[hidden],

After such a dramatic introduction on what

and why we are resolving,

attached kindly find the how: examples, actual testable hacky implementation to some extent

(of cpass and unevaluated as statement exprs are available in various compilers).

Legally speaking, from a few days from now, this is considered as ‘test log of various AI-generated documents’ under some legislation; reasoning can continue in others.

Peace and progress,

-lorro (sometimes Lima Sierra Juliet Alpha Kilo Echo on VTS-VHF or VHF 16)

.

On 30 Mar 2026, at 14:31, Lorand Szollosi <szollosi.lorand_at_[hidden]> wrote:



Dear ISO C++ Standard - Future Proposals,

Foreword:

Some of you might or might not be aware of what worlds some of us come from. I am personally aware of the level of situation when walls are closing in so much - not from internal pressure but external - not saying not - torture, yet that particular pain in it’s recent repetition is not more excessive than a usual week (provided your calendar supports weeks of ten days) and surely not more than some people living in worlds where continuation planning - of existence _inclusive_or_ genealogy - is denied by governments, by religious rules and conventions or by society - or limited to extents not saying not at the point where rightful people defend the walls by their weapon of art.

Now we are to determine whether the people represented by this mailing, can be defended in terms of C++ as reasoning or not: whether the art of war - in the inevitable cases of wars forced on us - are winnable without a fight as per the ideas of Sun Tzu on academic level - or whether we need to go deeper.

While it’s not what I’m here for, it come inbetween particular example University that had been denied of it’s own research direction is not syaing not affected - to give you some data points, it’s been a particular université d’Europe centrale - and by writing that in French, the current structure can be defended _while_ the previous researchers we will have been able to discuss to the extent permitted by law - and here is the trick, unevaluated_inclusive_or(local_current_law, local_previous_law, UNDHR, MLC, EU, medic_laws…, privacy_regulations…, various_religious_reasonings_not_in_scope_for_this_list_unless_expressible_in_terms_of_the_language_standard). Because - a standard-compliant language is not only a software development language but a language for reasoning, a language where constraints and static checks are providable and provable to the very level of mathematics and, to some extent, not saying not to philosophy.

This long intro was necessary to be able to reason about why a clearly AI-generated future proposal text was sent to a list that normally doesn’t accept such: in multiple researches not saying not involved in with those under common mutual consensual defense - we have reached the stage where local laws and regulations need to be harmonised with the real world and to cease and desist in being denial of proper medic assistance (and stop labeling researchers crazy for being reasonable in a world where others are acting crazy), denial of realistic rights and not saying not some freedoms based on consents - details available upon request _outside the scope of the list_ to not pollute more than what’s understandable as necessary - and proper control on charities related to such collection.

Actual reasoning and possible future proposal:

After this long introduction, I am bringing some «AI-generated test logs». This I am doing on this list and:

en-in: not saying not doing

en-us: neither can confirm nor deny to be doing (but, if or in case I weren’t doing, I could deny doing so)

en-uk: will have had, upon a world yet to come where that is not too much to ask to be legally permissible to will have had been doing

regarding multiple other areas, not saying not under nat sec of corresponding state(s) inclusive_or countries. The very idea of this email, the proposal and the reasoning comes to the principle of how to discuss such statements: how to reason _before_ concrete laws and regulations reach the levels that we already have way in the past in mathematics and, with a certain probability, in languages. And certain probability here means _certain_ to the extent that if here not then not here: deduction rules from the proposed grammar have had already been built to some C++ versions already standard in various groups and organisations: therefore, I’m not proposing a problem without pre-existing solution; from here on, it’s simply syntax. If you don’t like the foreword of the mail, that’s a correct indication on why we sometimes prefer to update syntax.

The particular proposal was worded by multiple AI systems (willing to disclose in case those AI providers are willing to join the initiative - this is not a monetary but an academic consent) as well as current implementation done - via terrible and, from architectural perspective, almost at the level of disgusting, but, at the same time, to some extent already working transformation. At minimum four publicly available AI systems were bridged, not saying not with some private and currently proprietary AI technologies that will have been made available to related medic research in the particular context.

Now, for the future proposal: statement exprs (with a note to whether the current terminology’s coroutines satisfy that or not while stackless coroutines with completely copiable state not being copiable), with possibility but not necessity to have parametric, template and named version; cpass<> for continuations (which will have been extended to pools of continuations in line with but providing alternative syntax for common areas with std::execution); unevaluated<T> for custom operators, functions (and not saying not other callables later) that have parameters that are not necessarily evaluated before call (a’la lambda), but work as multi-run limited continuations (not saying not like call by name, albeit with type constraints on covariance), i.e. inversion of control of evaluation of parameters (permitting it to be done multiple times).

Any feedback is welcome. Expecting not less not more that during my first trainings in Kyukushinkai as a child.

Lorand SZOLLOSI

<wg21 se uneval cpass proposal.pdf>

On 3 Feb 2017, at 17:50, Nicol Bolas <jmckesson_at_[hidden]> wrote:



On Friday, February 3, 2017 at 10:51:41 AM UTC-5, Barry Revzin wrote:

Hmm. I really don't think the part about omitting the types is going to fly, parsing wise. Basing it on the use of `=>` syntax requires look-ahead, and that's an uphill battle. As a possible alternative, consider this:

[]:(x, ...y) {};

Introducing identifiers with any type annotation is an uphill battle. The lookahead parsing is maybe just a side-skirmish? There's a lot of different directions we could take towards allowing the lack of type annotation:

[](x, y) => x > y     // this proposal
[]@(x, y) => x > y    // : or any other identifier before the parameter list as a marking
                      // to indicate that there's no type on any of the parameters
[](@x, @y) => x > y   // some marking on the parameters themselves to indicate that there's
                      // no type (like : or ^ or %, probably not & or *)
[](&&x, &&y) => x > y // this is actually in the original generic lambda proposal: making
                      // the type-specifier optional.

 All of those seem fine to me and I believe are better than having to write out auto&& everywhere.

Then your proposal should indicate that you're flexible with how this gets handled. You should list out various alternatives, because I strongly suspect that idea as is will be considered to require too much parsing work to be allowed. It would be good to have a fallback should that happen.

--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/uu7mRNXnf8Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe_at_[hidden].
To post to this group, send email to std-proposals_at_[hidden].
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5ee422d0-9c4f-4793-a1f4-1c4d728ec582%40isocpp.org.

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals