On Thu, Oct 23, 2025, at 18:01, John Bafford wrote: > 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.
I assume it is because you can't control the whole stack. For example, if you're calling file_put_contents(), you don't want it to cancel if a cancellation is received from outside the coroutine, which might put your application in a bad state. This goes back to including the reasoning in the RFC though, because I can only assume. — Rob
