Preparation for the next version of the RFC

[EdmondDantes]

This topic will contain links to other threads on various issues that remain open.

(the post will be updated)

You can propose your own questions for discussion. These may include function naming, edge cases, or other topics. Please base them on the current RFC.

Voiting:

• Naming: FutureLike, Future, Complition
• Select Cancalletion

Futures:

• Fiber support

Additional links:
https://discourse.thephp.foundation/t/php-dev-vote-true-async-rfc-1-6/4777/11

[EdmondDantes]

I have completed all research at this stage.

1. WordPress as a stateful application
2. Laravel Hello World
3. Revolt + AMPHP compatibility

Fiber support has been implemented. The Coroutine::getTrace method has been added.

Work on the next version of the RFC has started.

As a result, I decided to drop the Globals isolation feature. Most likely, it will not be included in the next RFC, because I do not see any robust solutions to the problems it tries to address. Globals isolation feels more like a workaround to avoid refactoring code. Yes, it works, but the same result can be achieved through automatic refactoring, or in the future, if there is sufficient demand, by adding it properly to PHP Core.

One of the reasons I did not include it in the RFC:

• there is no readonly policy

Ideally, if a new Superglobal were to be added, I would prefer it to be immutable, and this is currently not possible.

What did the research show?

The research showed and confirmed that a large amount of code works without any changes.
Code that stores global state and relies on DI must be modified to support a stateful mode.

Therefore, I decided to drop features such as:

• changing I/O behavior depending on the scope
• declare-based behavior depending on the file
• other similar ideas

All of this feels less like solving the problem and more like introducing new workarounds.
I do not want to turn PHP into a language of workarounds.

Creating single-threaded coroutines seems to me the only rational approach that is:

• balanced in terms of risks
• feasible to implement

Running coroutines in other threads would require a different API, new data-passing rules, and a new RFC that does not conflict with the current one.
Although, most likely, a large part of the current API would remain compatible with coroutines running in other threads.

[EdmondDantes]

https://wiki.php.net/rfc/true_async 1.7 version. Preview!