I guess my main thing is that this RFC should only cover coroutine machinery: it should not promise "transparent async" or "code
It’s like trying to dig a hole with half a shovel 
that works exactly the same" OR if it wants to make those claims, it should actually demonstrate
how instead of hand-waving everything as an "implementation detail" when none of those claims can actually be validated without those details.
All of my claims are backed by tests
On Sat, Nov 15, 2025 at 11:03 PM Edmond Dantes <edmond.ht@gmail.com> wrote:
Hello
It’s 1.6k lines so it might help a little bit
YeahWhy do you need reactor for this specific part of proposal? The thing is that there shouldn’t be any IO so you reduce scheduler code as well and make it simpler and more reviewable.
So you are suggesting removing all I/O from the RFC. On the one hand,
that sounds appealing. It immediately eliminates a bunch of tests. But
there is a trap we could all fall into.
By separating the reactor and the scheduler, as well as the rules of
how they work together, we might accidentally introduce an error into
the document simply because the documents would be split.
(interface drift)
I don’t see it that way. You have already implementation showing that this is workable for the proposed user interface so it’s just addition into that. I’m not sure how it could even impact user interface that is being proposed? If you are talking about internal interface, then it doesn’t matter, because this can be changed (you don’t have to keep BC there especially for such a new internal interface like this).
The fact that the I/O rules and coroutine rules are part of a single
document developed together is actually an advantage, just as the
existence of separate RFCs for await and Scope is.
But are I/O rules really part of this document? There are just a few mentioning of I/O and that seems more like a leftover from previous version to me. I don’t think it needs to keep reactor in there and mention I/O in other parts. It should just clearly put it to the future scope to make clear that this is something that is part of the plan.
Kind regards,
Jakub
On Sat, Nov 15, 2025 at 11:06 PM Edmond Dantes <edmond.ht@gmail.com> wrote:
I guess my main thing is that this RFC should only cover coroutine machinery: it should not promise “transparent async” or "code
It’s like trying to dig a hole with half a shovel
I think Rob has got a point that you don’t really need to give such promises that lack on details.
that works exactly the same" OR if it wants to make those claims, it should actually demonstrate
how instead of hand-waving everything as an “implementation detail” when none of those claims can actually be validated without those details.All of my claims are backed by tests
The problem is that no tests are really provided with the RFC in the PR that can be easily checked. I think it’s kind of a problem of all RFC’s that don’t have implementation (this one have but it’s really hard to extract). The people can only guess your intention but cannot really verify them as they could if there was implementation.
Kind regards,
Jakub
On Nov 15, 2025, at 16:20, Edmond Dantes <edmond.ht@gmail.com> wrote:
Hello.
An array_map() always blocks the thread but should never suspend.
This function is not related to this discussion or to the RFC.
function writeData() {
return array_map(function($elt) {
[$path, $content] = $elt;
return [$path, file_put_contents($path, $content)]; //POSSIBLE SUSPENSION POINT
}, $this->data);
}
Now this array_map function potentially suspends. As of course does this writeData(). And whatever calls this writeData(). And so on up the stack.
_Any_ function that calls any other function might have a hidden suspension point. And as Rob pointed out, any hook might also have a hidden suspension point, so you can't even trust code that doesn't look like it calls functions. And even if there are no hooks, __get(), __set(), etc are also there to ruin your day.
To provide an explicit example for this, code that fits this pattern is going to be problematic
Why is this considered a problem if this behavior is part of the
language’s contract?
Because this RFC *changes the contract* out from every line of php code ever written. Code that used to be strictly synchronous now has async suspension points it didn't ask for.
$this->data can be changed out from under writeData(), which leads to unexpected behavior.
So the developer must intentionally create two different coroutines.
Intentionally pass them the same object.
Intentionally write this code.
And the behavior is called “unexpected”?
Yes.
To repeat, a core premise of this RFC is:
• From a PHP developer's perspective, the main value of this implementation is that they DO NOT NEED to change existing code (or if changes are required, they should be minimal) to enable concurrency. Unlike explicit async models, this approach lets developers reuse existing synchronous code inside coroutines without modification.
• Code that was originally written and intended to run outside of a Coroutine must work EXACTLY THE SAME inside a Coroutine without modifications.
With this, the RFC implies that I should be able to take my synchronous PHP code and run it in a coroutine with other synchronous PHP code, and it will all just work. But obviously that won't work.
I understand that a different interpretation of this wording is, "well, that code does exactly what it did before, just that with coroutines, that happens to be broken". I could maybe squint and grunt disapprovingly about it being "technically correct", except "has a suspension point" is *definitely not* exactly how it worked before.
The changes described in the RFC refer to the algorithm for handling
I/O functions in blocking mode. And of course these words assume that
we haven’t lost our minds and understand that you cannot write
completely different message sequences to the same socket at the same
time. In practice, changes are of course sometimes necessary, but
throughout my entire experience working with coroutines, I should note
that I have never once run into the example you mentioned. Even when
adapting older projects. And do you know why? Because the first thing
we refactored in the old code was the places with shared variables.
Well, but that's not what my example was doing. My example was taking a set of (filename, content) pairs and writing them to individual files. But it was doing it in an async-unsafe way (because that has never before been a consideration), and so its data source can be corrupted _while it is executing_.
The async problems in my example might be glaringly obvious (for people skilled in the art), but many other async issues are much more subtle, such as Rob described in his follow-on email to mine. For people who have never had the pleasure of working with async code before, "the world changed out from under me" is not a scenario you're accustomed to thinking about.
But in PHP, colored functions are inconvenient. Overloading I/O
functions does not lead to serious errors that make developers suffer;
on the contrary, it saves time and gives the language more
flexibility.
Of course colored functions are inconvenient. But it's necessary or else you open to a whole class of easily avoidable problems. _Those_ problems are _much_ more inconvenient than colored functions.
Code that was written to be synchronous should remain synchronous unless it is explicitly modified to be asynchronous.
A developer should strive to minimize asynchronous code in a project.
The less of it there is, the better. Asynchronous code is evil. An
anti-pattern. A high-complexity zone. But if a developer chooses to
use asynchronous code, they shouldn’t act like they’re three years old
and seeing a computer for the first time. Definitely not. This
technology requires steady, capable hands
What this says to me is, "Here's a foot-gun. Please use it responsibly."
Now, I definitely want to have advanced features available for when they're needed. But that said, It would be great if we can avoid introducing new foot-guns, especially when we have the knowledge and experience from other languages to draw on and do better. And when we do introduce new foot-guns, it's better if we can make them strategically-targeted sniper rifles instead of blunderbusses.
If we allow for hidden async behavior, the entire system becomes impossible to reason about. Some library I'm using can cause an async race condition without me asking for it, and I can't know it doesn't unless I audit it and its interaction with my code.
And we know from practice that enough people won't use async responsibly that it will make the language look bad. What will happen is a junior dev will decide (or be told) that some code is performing poorly and they will see a forum post that says "use coroutines" or "use async" and they will cargo-cult their way to a hidden problem because they didn't take into consideration the full problem space. Not to say that can't happen with explicit suspensions, but the ceremony of declaring you have a possible suspension at least gives a pointer of, "this is where there's a suspension; what happens if it does?".
-John
I’ve been reading this discussion from the peanut gallery. I don’t have enough knowledge to really add anything to the conversation, but I do want to take a moment to thank everyone involved. Of the changes to PHP since 7, this promises to be some of the most significant. The care and time taken to get this right is greatly appreciated. To all participants of the thread, thank you.
On 2025-11-16 04:21, Edmond Dantes wrote:
RFC: "A coroutine can stop itself passing control to the scheduler.
However, it cannot be stopped externally."which essentially means the same thing.
Oh ... there's an ambiguity in that line. "I'm now going to pass control to the scheduler ... no, no I won't; that's exactly what they'll be expecting me to do."
I suggest rewriting the sentence as:
"A coroutine can stop itself and pass control to the scheduler."
or
"A coroutine can stop itself, passing control to the scheduler."
Hello.
I think Rob has got a point that you don't really need to give such promises that lack on details.
The problem is that the phrase from the RFC is being interpreted in a
distorted way, and meaning is being attributed to it that it never
had. Not to mention the fact that real-world facts are being ignored.
The problem is that no tests are really provided with the RFC in the PR that can be easily checked.
I think it's kind of a problem of all RFC's that don't have implementation (this one have but it's really hard to extract).
The people can only guess your intention but cannot really verify them as they could if there was implementation.
This RFC has more than 300 tests that you can review. They’re also
sorted into folders, have descriptions, and are quite easy to read.
There are also two Dockerfiles for this RFC that let you run PHP 8.6
and try all the features with a single command.
But wait, this is only the beginning of the fun.
The funniest part is that this RFC has effectively existed in the real
world for many years (7 or 10?), and there are entire teams of
developers who have been using PHP according to this RFC for a long
time.
And even if this project had no code at all, you can at any moment
take Swoole or Swow, try PHP on steroids with real code, and see how
this RFC affects existing code.
I would understand if this RFC were proposing something very new,
something that had never existed in PHP before. But the irony is that
it proposes to standardize what has already been in PHP for many years
but has never been made a standard. And instead of discussing
implementation details, we’re discussing that 2 + 2 ≠ 5.
Now this array_map function potentially suspends. As of course does this writeData(). And whatever calls this writeData(). And so on up the stack.
And the most important thing is that the __execution flow__ for this
function will __not change__.
Do you understand this?
This is described very clearly in the RFC.
Because this RFC *changes the contract* out from every line of php code ever written. Code that used to be strictly synchronous now has async suspension points it didn't ask for.
It’s not the RFC that changes the contract. It’s asynchronous
programming that changes the contract. And that lies outside the scope
of this RFC, because once a developer starts using asynchronous
programming, they must accept the global contracts of asynchronous
execution.
And this RFC does not deny that.
To repeat, a core premise of this RFC is:
Sorry, but I’m not going to repeat points that were ignored. My goal
is to help you understand the text of this RFC. I have no intention of
banging my head against a wall.
With this, the RFC implies that I should be able to take my synchronous PHP code and run it in a coroutine with other synchronous PHP code, and it will all just work. But obviously that won't work.
For most cases that’s exactly how it works.
In human language, there is no definition that cannot be twisted and
misinterpreted. Why elevate this idea to an absolute while ignoring
common sense? I have no idea. What’s the purpose of this discussion?
It seemed to me that the purpose of the discussion was a professional
conversation, not playing with meanings.
I understand that a different interpretation of this wording is, "well, that code does exactly what it did before, just that with coroutines, that happens to be broken".
I have no idea what you’re talking about.
Of course colored functions are inconvenient. But it's necessary or else you open to a whole class of easily avoidable problems. _Those_ problems are _much_ more inconvenient than colored functions.
I already discussed this topic back in March, and I can briefly
summarize: the absence of colored functions in PHP is the only viable
way to implement async.
Code that was written to be synchronous should remain synchronous unless it is explicitly modified to be asynchronous.
Practice has proven the opposite.
What this says to me is, "Here's a foot-gun. Please use it responsibly."
A footgun implies something hidden or implicit.
Asynchronous programming requires the developer to handle memory
correctly explicitly. This is equally true for all programming
languages.
It does not relate specifically to this RFC.
especially when we have the knowledge and experience from other languages to draw on and do better
How do you plan to draw on the experience of other languages if you’re
ignoring the experience of asynchronous PHP that has existed for many
years? If you truly wanted to rely on such experience, there wouldn’t
be this discussion.
On Sat, 15 Nov 2025 at 21:15 Michael Morris <tendoaki@gmail.com> wrote:
I’ve been reading this discussion from the peanut gallery. I don’t have enough knowledge to really add anything to the conversation, but I do want to take a moment to thank everyone involved. Of the changes to PHP since 7, this promises to be some of the most significant. The care and time taken to get this right is greatly appreciated. To all participants of the thread, thank you.
As another bystander of this RFC, I can’t help but feel that too much effort is being put into an RFC where the author is eager to take it to a vote that is likely to fail. There doesn’t seem to be anybody else clearly understanding the entire RFC and there are a lot of room for confusion for voters, PHP users and core maintainers.
Maybe that’s inherent to a subject matter that indeed could be the biggest change to PHP since 7, but given RFC voting history, all signs point to a rejection vote. I don’t know how much has been discussed off list and/or how many voters are involved off list.
At a very minimal, Async PHP would be interesting. A door to a new universe seems more fitting to describe its impact, but I don’t know how this RFC can be helped into a more likely successful outcome - or if my limited pessimistic view of its results are even valid concerns.
Hello, Morgan
I suggest rewriting the sentence as:
"A coroutine can stop itself and pass control to the scheduler."
Thanks.
I would also add that a coroutine cannot be stopped from the outside.
Will this be ok?
Hello
Maybe that’s inherent to a subject matter that indeed could be the biggest change to PHP since 7,
but given RFC voting history, all signs point to a rejection vote.
I think so too.
I don’t know how much has been discussed off list and/or how many voters are involved off list.
There were almost no discussions apart from the one on INTERNALS. I
mean, there were no discussions that I’m aware of.
I don’t know what to do about a situation where PHP developers are
surprised to learn that their language has supported transparent
asynchrony as a core paradigm for several years already.
And instead of discussing the important details of the RFC, all the
effort goes into “basic questions” that aren’t worth discussing at
all.
It would be wonderful if there were a dedicated person whom everyone
would listen to carefully and who could explain the basic questions
privately. Most likely, this approach would solve many problems.
---
Best Regards, Ed
Hi,
On Sun, Nov 16, 2025 at 5:22 AM Edmond Dantes <edmond.ht@gmail.com> wrote:
Hello.
I think Rob has got a point that you don’t really need to give such promises that lack on details.
The problem is that the phrase from the RFC is being interpreted in a
distorted way, and meaning is being attributed to it that it never
had. Not to mention the fact that real-world facts are being ignored.
Well I can see why this phrases are confusing for some users. The thing is that saying that something will behave exactly the same omits the fact that it introduces the new suspension points that can have side effects. This might be clear to you but I can see why it’s not clear to others. I think this is really more wording issue and you should make it clearer or not to claim it at all.
I think what could help is to also add a section comparing the coloring approach and why you think this is a better for PHP.
The problem is that no tests are really provided with the RFC in the PR that can be easily checked.
I think it’s kind of a problem of all RFC’s that don’t have implementation (this one have but it’s really hard to extract).
The people can only guess your intention but cannot really verify them as they could if there was implementation.This RFC has more than 300 tests that you can review. They’re also
sorted into folders, have descriptions, and are quite easy to read.
There are also two Dockerfiles for this RFC that let you run PHP 8.6
and try all the features with a single command.
But that’s in your php-src branch + extension code so it’s very hard for everyone to find and even harder to try. My argument was that this should be extracted in the minimal form to the PR so people can see what’s being proposed and don’t need to guess based on the RFC content.
Kind regards,
Jakub
Hi,
On Sun, Nov 16, 2025 at 7:58 AM Edmond Dantes <edmond.ht@gmail.com> wrote:
Hello
Maybe that’s inherent to a subject matter that indeed could be the biggest change to PHP since 7,
but given RFC voting history, all signs point to a rejection vote.I think so too.
It looks like it but it’s hard to say because many people have not had chance to review / comment on this. I think it needs more time and the RFC text needs more work to explain the basic difference. I think it also need to have a good implementation for what is being proposed to have any chance because there are often voters that will vote down just because there is no implementation that can be reviewed. Basically everything that can be addressed should be addressed before the vote so it’s just decisions between the actual approach.
I don’t know how much has been discussed off list and/or how many voters are involved off list.
There were almost no discussions apart from the one on INTERNALS. I
mean, there were no discussions that I’m aware of.I don’t know what to do about a situation where PHP developers are
surprised to learn that their language has supported transparent
asynchrony as a core paradigm for several years already.
And instead of discussing the important details of the RFC, all the
effort goes into “basic questions” that aren’t worth discussing at
all.
I think this is more that some people clearly prefer coloring and want to point out the potential issues with this approach. This might be quite hard to overcome and depends how many voters have such preference. Personally I agree that coloring would be bad for PHP as I was dealing with “coloring migration” in Python and it wasn’t nice. That’s why I think it might help to have dedicated section about coloring (more comparison with the current approach) in the RFC.
Kind regards,
Jakub
Hello.
RFC authors are the subject-matter experts for their proposals, and the way the process succeeds is by the author being willing to explain, restate, clarify, and anchor concepts for people coming from different backgrounds and
different levels of familiarity.
For the discussion to be constructive, there has to be a shared desire
to reach a common goal.
It sometimes feels like I am the only one who needs asynchrony
PHP does not have many options for implementing asynchrony.
Why?
1. Colored functions require the language to support two runtimes. For
PHP this is an anti-pattern. A single unified runtime is the key
feature of the language.
2. Any code with global state inside coroutines will not behave as
expected. This is not a property of this RFC but of any asynchronous
code. I can add this sentence, but last time I was asked to remove
wording that sounded alarming.
True Async, Swoole, and Swow follow the same idea. Different
implementations, but the same logic. AMPHP and React differ only in
that they do not intercept PHP functions, but they still use the same
technology, the same algorithms, and the same approach.
TrueAsync was originally written with code from AMPHP, so you can see
microtasks that AMPHP borrowed from JavaScript. Later, it adopted some
techniques from Swoole.
In other words, PHP has had a de facto coroutine approach for many
years, but no one has ever standardized it. There is an approach and
there are implementations, but there is no RFC.
Do you understand why this RFC is written the way it is?
Why does the RFC state that code does _not need to be changed_?
Because in AMPHP and React you cannot simply take your code and run it
inside a coroutine.
So you must replace all PHP functions with special ones.
This does not mean that a developer should forget about memory or
corner cases. There is no silver bullet in programming.
Do we really need to add a disclaimer under every statement that there
are always exceptions? In programming, every statement has exceptions.
What about colored functions. I recently explored a hybrid approach.
Its logic is relatively simple. The compiler allows writing async next
to a function, and then it automatically infects other functions. At
the same time there is a special word noasync that prevents the
compiler from automatic “infection.” Something similar can be
implemented in PHP using attributes or static analysis. This would
make the code more predictable while keeping it flexible. This RFC
does not conflict with that approach at all, and it can be implemented
in the future if there is a desire to make the language stricter.
On Sat, Nov 15, 2025, at 23:06, Edmond Dantes wrote:
I guess my main thing is that this RFC should only cover coroutine machinery: it should not promise “transparent async” or "code
It’s like trying to dig a hole with half a shovel
that works exactly the same" OR if it wants to make those claims, it should actually demonstrate
how instead of hand-waving everything as an “implementation detail” when none of those claims can actually be validated without those details.All of my claims are backed by tests
I will leave with some final advice. The problem with tests is that they only validate the current implementation, which isn’t guaranteed to be the final implementation. I would recommend reviewing your tests and matching up each of them to where you mention that behavior or define it in the RFC. If the tests are implementation-specific, then it needs to be defined in the RFC. For example, you say that the scheduler is 100% an implementation detail, but your outputs in the tests rely on a specific ordered queue. You should at least define the ordering the queue should be processed in the RFC (LIFO vs FIFO) so that even if the implementation changes, the tests still pass.
That’s one example, you can review my previous comments to discover other examples, such as defining the rules of suspension points.
I wish you the best,
— Rob
I think it needs more time and the RFC text needs more work to explain the basic difference.
I do not mind, but no one is writing anything.
(El coronel no tiene quien le escriba :))
I think it also need to have a good implementation for what is being proposed to have any chance because there are often voters that will vote down just because there is no implementation that can be reviewed.
Basically everything that can be addressed should be addressed before the vote so it's just decisions between the actual approach.
Perhaps, but no one has said that the current implementation is bad or
needs to be replaced.
I mean that so far no one except you has said this.
It seems to me that no one except a few people has actually looked at
the implementation. I am almost certain of that.
There has never been a conversation like “Yes, this RFC is fine, but
it needs a different implementation.”
I think this is more that some people clearly prefer coloring and want to point out the potential issues with this approach.
If someone in this discussion had actually written about the real
issue of not having colored functions, it would have been great and
extremely useful. No one did.
Most people simply have not encountered these problems. Colored
functions sometimes help localize errors related to global state. Not
always, but sometimes.
But there is also the opposite situation. The tragedy of the Python
async migration which slows down the adoption of async in Python.
Speaking more seriously, colored functions are more useful for
low-level languages. For high-level languages, the absence of colored
functions and full commitment to asynchronous code is actually more
beneficial. Languages that follow this path, like Go, have succeeded.
Why is that? Because high-level languages can hide contracts.
Low-level languages have the opposite requirement: they need to know
every contract explicitly. This happens because increasing abstraction
relies on hiding details.
That's why I think it might help to have dedicated section about coloring (more comparison with the current approach) in the RFC.
In the early versions there was similar text, but I removed it so it
wouldn’t overload the RFC. But in short, the absence of colored
functions simply saves time.
----
Best Regards, Ed
This thread is a clear, explicit and direct representation that there are people following all the hard work that you’ve put into this RFC. I dare say that nobody doubts your intentions, effort and initiative to tackle such a complex and hard task.
The next step is to recognize that anybody participating in an RFC discussion is a person taking time out of their lives, their family, their work, their hobbies and volunteering their time similar to you. Everyone has PHP best interest at heart even if what we think is best for PHP differs.
On Sun, 16 Nov 2025 at 03:56 Edmond Dantes <edmond.ht@gmail.com> wrote:
Hello
Maybe that’s inherent to a subject matter that indeed could be the biggest change to PHP since 7,
but given RFC voting history, all signs point to a rejection vote.I think so too.
I don’t know how much has been discussed off list and/or how many voters are involved off list.
There were almost no discussions apart from the one on INTERNALS. I
mean, there were no discussions that I’m aware of.I don’t know what to do about a situation where PHP developers are
surprised to learn that their language has supported transparent
asynchrony as a core paradigm for several years already.
I suppose you’re referring to Swoole, AMPHP, ReactPHP, etc. While there’s no denying they’re an important part of the ecosystem and living proof there’s room for asynchronous PHP, your positioning here seems to assume that everybody participating in your RFC should know, understand and use one of these projects and have that baseline knowledge. From my personal experience, context and little bubble, I would guess that less than 10% of PHP engineers worldwide has any firsthand experience with any of these tools combined. Your RFC can bridge that gap, but to do so you need to be able to address why the other 90% hasn’t used any of these existing approaches. Your target audience is exactly the opposite of what you expect.
And instead of discussing the important details of the RFC, all the
effort goes into “basic questions” that aren’t worth discussing at
all.
This is perhaps the most likely reason for the RFC to fail a vote. Let’s break down voting in an abstract format. Some common reasons voters may choose to vote NO are:
There’s not much you can do about 1. And for every NO you get, you need 2 YES to overcome it.
My personal guess is that 4 would drive a lot of NO and the reason is a combination of factors. It’s a very complex and dense RFC and not every voter will have any experience with the existing async tools provided by the community. When trying to take time out of their personal lives to go through such a complex and extensive RFC, basic questions will arise. They will attempt to address it before going deeper and deeper and will be met with a dismissive response from the author “because this is too basic and we shouldn’t focus on it”. They will make the easy choice to not continue to volunteer their time into something so hard to wrap your head around since it’s too challenging to even get past the basics. A negative result is not really a surprise at this point.
It would be wonderful if there were a dedicated person whom everyone
would listen to carefully and who could explain the basic questions
privately. Most likely, this approach would solve many problems.
Best Regards, Ed
Short of forking PHP, that seems like wishful thinking. PHP is driven by committee and there doesn’t seem to be any way around that. But there are approaches you can try.
One of them is pairing it up with someone better at docs, communication, etc. Take a look at Larry’s RFCs. Majority of it he doesn’t write any C code, but he makes up for it 10 times by producing clearly readable, understandable and decision points communicated. Voters may still disagree at the end, but it always feels like they understand what they’re voting on/for.
I don’t know if you’re good with a camera, but going in a podcast with someone like Brandt, Nuno Maduro or any other PHP podcast that tries to breakdown internals for easy consumption could also help your cause.
Ultimately, I think your vast expertise on the matter is both a blessing and a curse. A blessing because without it maybe the RFC would have never even existed - at least no other RFC on the matter has reached so far. A curse because nobody else seems to be able to understand what you’re saying, what you’re doing and what PHP will be like if your RFC is approved.
As someone writing PHP for 15 years, I’m scared of bringing any async community tools to any project I work because I don’t know what would break. Your RFC states that you want all my code to keep working which is great, but the moment I make use of something async it could inadvertently affect something and I don’t know what/why/how. I’m dumb and don’t know how async works and I don’t want PHP to allow me to shoot myself in the head like that. Is there anything you can do about it?
I wish you all the best luck on the RFC and your next steps. I thank you for all your time so far and I’m eager to see what come out of it.
I would recommend reviewing your tests and matching up each of them to where you mention that behavior or define it in the RFC. If the tests are implementation-specific, then it needs to be defined in the RFC.
Yes, in some tests I break best practices and rely on implementation
details to verify behavior. This makes the tests fragile.
For example, you say that the scheduler is 100% an implementation detail, but your outputs in the tests rely on a specific ordered queue.
Yes, I’m a lazy programmer
I wish you the best,
Thank you.
---
Best regards, Ed
why the other 90% hasn’t used any of these existing approaches
Five or more years ago, when the question of improving performance
came up and Swoole was being considered, I rejected it. Why? Because
it wasn’t part of PHP. That was the reason.
If Swoole became the PHP standard, our company would most likely switch to it.
Because support from the PHP community is a long-term guarantee, which
means the time and money invested will not be wasted.
Your target audience is exactly the opposite of what you expect.
If my audience consists of people who need new knowledge, that’s a
different story!
A negative result is not really a surprise at this point.
I don’t see any way to make this RFC clearer.
I doubt the problem is in the text.
They will attempt to address it before going deeper and deeper and will be met with a dismissive response from the author “because this is too basic and we shouldn’t focus on it”.
The problem is not a lack of willingness to discuss the basics, but
that the discussion should move toward clarifying the details. And
that is exactly what isn’t happening.
As you correctly noted, no one wants to waste their time for nothing.
I also don’t want to spend my time on a conversation with no result.
I don’t know if you’re good with a camera, but going in a podcast with someone like Brandt, Nuno Maduro or any other PHP podcast that tries to breakdown internals for easy consumption could also help your cause.
No problem with the camera. But I cannot speak English fluently.
A curse because nobody else seems to be able to understand what you’re saying, what you’re doing and what PHP will be like if your RFC is approved.
I have a small presentation that I prepared for TrueAsync, and I could
adapt it to the questions of this RFC.
But...
I know that the PHP community has specialists in asynchronous PHP who
are better than me.
All the experts from Swoole, Swow, AMPHP, React, and so on. That’s not
two or three developers.
In the previous discussion, Daniil Gentili wrote an amazingly professional post.
I’m scared of bringing any async community tools to any project I work because I don’t know what would break.
That was my first reaction several years ago.
Your RFC states that you want all my code to keep working which is great, but the moment I make use of something async it could inadvertently affect something and I don’t know what/why/how.
I’m dumb and don’t know how async works and I don’t want PHP to allow me to shoot myself in the head like that. Is there anything you can do about it?
In that case it’s better to choose a programming language like Elixir, Erlang.
PHP will not provide the required level of memory safety, although it
may be possible to add a special type of static variables to it.
I wish you all the best luck on the RFC and your next steps. I thank you for all your time so far and I’m eager to see what come out of it.
Thank you.
--- Ed
On Sun, Nov 16, 2025 at 1:14 AM Michael Morris <tendoaki@gmail.com> wrote:
I’ve been reading this discussion from the peanut gallery. I don’t have enough knowledge to really add anything to the conversation, but I do want to take a moment to thank everyone involved. Of the changes to PHP since 7, this promises to be some of the most significant. The care and time taken to get this right is greatly appreciated. To all participants of the thread, thank you.
I’ll add myself to the Thank You-list. Thanks everyone, but especially Edmond, for having the courage and bravery to tackle such a big and complex topic. Your patience is virtue and I think you’re showing a lot of it; I hope it will be enough 
I for one hope we’ll get this version of async, to me it checks everything I’d expect and need from PHP and this way of backwards compatibility or basically compatibility with most existing code is truly intriguing.
Again, thanks to everyone.