| |
| Posted by Richard (Rikki) Andrew Cattermole in reply to Atila Neves | PermalinkReply |
|
Richard (Rikki) Andrew Cattermole
Posted in reply to Atila Neves
| On 14/01/2025 6:59 AM, Atila Neves wrote:
> I had trouble understanding the proposal. If I didn't already know what a coroutine is, I wouldn't have found out by reading the abstract. There are a few sentences I didn't understand in their entirety either such as "If it causes an error, this error is guaranteed to be wrong in a multi-threaded application of it.".
I do not understand why you are having trouble with it.
It has not come up before and Gemini understood it.
It is short, precise and complete to what I mean.
If you want me to change it, I need a lot more feedback including:
- How you are interpreting it
- What questions you had after reading it
- what did you expect it to contain
As it currently stands this is not constructive feedback, there is nothing I can do with it. I do not understand what problems you are having with it.
> It also seems more complicated than what other languages have, and I'm not sure why that is.
Its not more complicated, but I can understand that it may appear that way.
Other languages can tie the feature to a specific library, which will not work for us.
Consider why we cannot: a coroutine language feature is tied to its representation in library, which is tied to is eventloop, which is tied to sockets, windowing, pipes, processes, thread pool ext.
None of which can be in druntime, has to be Phobos. But we cannot tie a language feature to Phobos, and if we do that I cannot experiment prior to PhobosV3 to ensure it both works as expected and to learn if any further expansion is needed.
Also coroutines are used in both generative and event handling basis, they are not the same library wise. Tieing it to just one is going to be hell for someone. Most likely me as I'm responsible for the user experience.
> Why |@async return| instead of |yield|?
Then ``yield`` would be a keyword, which in turn breaks code which is known to exist.
There is no benefit to doing this. But we _could_ do it.
However there is a good question here, why not combine ``await`` statement with ``@async return``? Well the answer is you may want to return a coroutine, which couldn't be differentiated by the compiler.
> Why have to add |@async| to the grammar if it looks like an attribute?
All language attributes are in the grammar, there is nothing special going on there.
https://dlang.org/spec/grammar.html#attributes
|