On Thu, Oct 23, 2025, at 18:01, John Bafford wrote:
> Hi,
>
> > On Oct 23, 2025, at 01:56, Edmond Dantes <edmond.ht@gmail.com> 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