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@gmail.com> 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:
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@isocpp.org.
To post to this group, send email to
std-proposals@isocpp.org.
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.