Hi, > On Oct 23, 2025, at 01:56, Edmond Dantes <[email protected]> wrote: > > 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 don't have any specific use-cases in mind. I'm just trying to be forward-looking here. But what is clear is that some people would like to see async/await in PHP. This RFC would ostensibly be a step towards that. All I'm trying to do is make sure that it doesn't put up roadblocks for future enhancements. >> 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. I think there are two bad designs here. First: If you have something that streams results, then the interface to access should reflect streaming. And it should be an error (preferably thrown at compile time) if you try and treat a stream as a single value, or a single value as a stream. This is whether it's async or not. And we already have an interface one can implement if one has an iterable sequence of events, so that you can either call the iteration functions directly, or use foreach() which provides syntactic sugar over that. Second: it should be emitting either a stream of files, or a stream of arrays of files. Returning list<File>|File is not a great pattern. >> 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 ? That's the first review thread for Swift's Structured Concurrency proposal. The proposal itself is here, along with links to the three pitch and three review threads, and the async/await and actor proposals: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0304-structured-concurrency.md (see also the async/await and actors proposals, linked from that proposal. Note that a nontrivial portion of the proposal covers actor isolation, which is obviously beyond the scope of this RFC, but whether or not a future multithreading async extension uses actor isolation as its safety concept, those concepts are still generally relevant.) >> 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. Why is the protect function needed, then? If you request cancellation, the coroutine is free to ignore the cancellation and run to completion. That's what makes it cooperative. >> 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 :) In addition to Rob's comments on expressing intent and a source for documentation: concurrency is a large, confusing, and _hard_ topic. Anything that's unclear or underspecified is only going to cause problems in the long run. It's better to be as clear as possible so that when it eventually comes to voting, you have less chance of people voting No because of that reason. > Thanks, Ed -John
