Hi Zhao Yun Shan,

The paper you wrote details some mechanisms, but it does not address the most important aspects of a paper, those being:

- a survey of the problem space the proposed solution is supposed to solve
- a review of prior attempts at solving those problems, their deficiencies, and a description of why the proposed solution is better than those
- for this particular problem space: a review of p2300 and a discussion of why the proposed solution is better than the one that has already been proposed and actively worked on for years
- why this solution needs to be standardized in the standard library as opposed to just being a library you can get from github and use it without standardizing it

Any committee member can give you a paper number and publish your paper, but you need to be available for discussion of it and defend it, otherwise it will go nowhere. The above questions will be the first questions anyone asks before considering it a viable solution.

Thank you,

Gašper

On Sun, Mar 3, 2024 at 11:43 AM zys <dou1984@163.com> wrote:

     Hi,  I have already completed the relevant paper, but I don’t know how to publish it. The paper is located at the following address:
     https://github.com/dou1984/coev/blob/main/paper/An%20efficient%20event-driven%20coroutine%20solution.md
     Please forgive any expression or grammar errors in the paper.


At 2023-10-03 07:05:15, "Gašper Ažman" <gasper.azman@gmail.com> wrote:

Dear ZYS,

I think you might want to know how the committee proposals work. If you want something to be accepted by the standard, you need to bring a paper, it's not common for someone else to write a paper on your behalf. People will help you with the procedural stuff, but they are unlikely to take the time to help with writing.

Once you have a paper that describes in detail how your design differs from p2300, the committee can have a discussion about it.

G

On Mon, Oct 2, 2023, 17:38 zys via Std-Proposals <std-proposals@lists.isocpp.org> wrote:


hi,


I have read "P2300R7 std::execution Published Proposal" before. But I think my implementation was more convenient, so I send the message。


The library main codes are all in this directory.:https://github.com/dou1984/coev/tree/main/src/coev


At 2023-09-29 21:23:48, "Jens Maurer" <jens.maurer@gmx.net> wrote: >Hi, > >I'd suggest that you read https://isocpp.org/std/submit-a-proposal in detail. > >You've shown a few coroutine-based examples on that page, but it's unclear >to me what the actual interface to the underlying functionality is. > >Which part does your library provide, and which part does the user have >to provide? A Redis client library, for example, is not part of the >C++ standard. Do you propose to make it so? > >Please also see P2300 for a more general execution framework > >https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2300r7.html > >(including interfacing with coroutines), and > >https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2762r1.pdf > >for integrating networking in that sender/receiver framework. > >What does your library offer that the combination of these two >proposals does not provide? > >Jens > > >On 29/09/2023 15.09, zys via Std-Proposals wrote: >>    The c++20 coroutine is a high-performance coroutine solution, but it has not become popular, because there is no encapsulation that satisfies everyone. >>    The author provides a set of event-based encapsulation to separate from IO, network, and business code. Developers no longer need to implement coroutine encapsulation and can quickly convert existing asynchronous programs into coroutine programs. >> >>     The author's source code address is:https://github.com/dou1984/coev <https://github.com/dou1984/coev> >>
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals