Hi, > it makes that future RFC's job unnecessary harder
If you want to make PHP multithreaded and plan to change the language syntax while avoiding future issues, it would be reasonable to discuss the changes using specific syntax examples. Can you show me the cases you want to implement? > I can't find where this `awaitXX` function is defined It was in the third version of the RFC. > So you say "Awaitable objects do not return multiple values. 1. multiple values: ```php $fs = new FileSystemEvents(); // At that moment, the user created file1 and then file2. $event = await($fs); // Now: $event contains [file1, file2] -- The coroutine captured two events at once. ``` 2. signe value: ```php $fs = new FileSystemEvents(); // At that moment, the user created file1 and then file2. $event = await($fs); // Now: $event contains file1 -- ONLY ONE VALUE! ``` > but to me it feels like you're just dismissing Rob and my concern It’s hard three times over, because the expression foreach(await() as ) is considered valid only if await returns a value once. > And Swift does recognize this as a problem I don’t know whether Swift actually recognizes it as a problem or not, but it actively uses syntax to describe contracts. And that’s a slightly different level of control compared to just functions and interfaces. Let me repeat the main conclusions: 1. There’s no problem making `FutureLike` the base interface, which would guarantee the idempotence of the data source. 2. The benefit is that calling `await` twice would become more predictable (although the data type would still be unknown). 3. However, we would lose an interface that describes the real world as it is, and the programmer would lose some flexibility. 4. Yet, considering that non-idempotent `Awaitable` objects, while allowed, are rarely used in high-level languages, this may not actually be a problem. > Then, just saying, this is a place where people are going to be confused, and > it needs to be stated clearly. I don’t mind; I should take a look at this point. > btw, if you haven't read through the Swift Evolution proposals for structured > concurrency, Thanks for the idea. I haven’t read that discussion. Is it https://forums.swift.org/t/se-0304-structured-concurrency/45314 ? > What I'm proposing that specifically Async\protect() and *forcibly* > cancelling coroutines should be removed. This RFC does not include forced coroutine termination, only cooperative cancellation using exceptions. If we remove the protect function, we’ll also have to remove cooperative cancellation. > You'll note that in some multithreading APIs, forcibly terminating threads, > while allowed This feature was implemented in Swow using the VM interruption mechanism. That’s why I wrote that such a solution is possible if someone needs it, but it has nothing to do with either protect or cooperative cancellation. > The RFC should include a description of _why_ cooperative cancellation has > been chosen. If I add detailed explanations for every _why_ in the RFC, it might never get read :) Thanks, Ed
