PHP: rfc:async_scheduler_abi

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== PHP RFC: Your Title Here ======
  * Version: 0.9
  * Date: 2026-01-01 (use today's date here)
  * Author: Your Name, your_email_address@example.com
  * Status: Draft (Later in the RFC process "Under Discussion", "Voting", and finally "Accepted", "Declined" or "Implemented")
  * Implementation: https://github.com/...
  * Discussion thread: https://news-web.php.net/php.internals/… (The email should appear on https://news-web.php.net/php.internals/ a few minutes after sending it)
  * Voting thread: tbd

This is the suggested template for PHP Request for Comments (RFCs). Change this template to suit your RFC. Not all RFCs need all the sections below.

Please read https://wiki.php.net/rfc/howto carefully!


Quoting [[http://news.php.net/php.internals/71525|Rasmus]]:

> PHP is and should remain:
> 1) a pragmatic web-focused language
> 2) a loosely typed language
> 3) a language which caters to the skill-levels and platforms of a wide range of users

Your RFC should move PHP forward following his vision. As [[http://news.php.net/php.internals/66065|said by Zeev Suraski]] "Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases [...] Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring."

===== Introduction =====
The elevator pitch for the RFC. The first paragraph of this section will be rendered slightly larger to give it emphasis.

Please write an introduction that helps people by providing concise context and include a representative small code snippet.

<PHP>
<?php

echo "Showcase your idea here";

?>
</PHP>

===== Proposal =====
All the features and examples of the proposal.

To [[http://news.php.net/php.internals/66051|paraphrase Zeev Suraski]], explain how the proposal brings substantial value to be considered for inclusion in one of the world's most popular programming languages.

Please clearly specify the desired syntax and semantics of your proposal, for example the interactions with existing PHP functionality, and please mention all edge cases, including potential gotchas.

Include stubs for newly introduced functions classes and constants, including namespaces and types.

<PHP>
<?php

namespace Example\Component {
    final class NewAddition {
        public static function fromString(string $example): self {}
    }
}

?>
</PHP>

==== Examples ====
Remember that the RFC contents should be easily reusable in the PHP Documentation. This means, if at all possible, they should be runnable as standalone, self-contained code with the proof-of-concept implementation.

Simple example:
<PHP>
<?php

echo "First example";

?>
</PHP>

Example showing an edge case:
<PHP>
<?php

echo "Edge case";

?>
</PHP>

===== Backward Incompatible Changes =====
What breaks, and what is the justification for it?

Please include all breaking changes, no matter how minor they might appear. All research you did on potential impact should be listed in this section.

For adding new functions, classes or keywords, here are some possibilities to measure potential impact:

  * A script from nikic that checks the top 1000 Composer packages https://gist.github.com/nikic/a2bfa3e2f604f66115c3e4b8963a6c72
  * GitHub regexp search
  * https://grep.app/
  * https://about.sourcegraph.com/

===== Proposed PHP Version(s) =====
List the proposed PHP versions that the feature will be included in. Use relative versions such as "next PHP 8.x" or "next PHP 8.x.y".

===== RFC Impact =====
==== To the Ecosystem ====
What effect will the RFC have on IDEs, Language Servers (LSPs), Static Analyzers, Auto-Formatters, Linters and commonly used userland PHP libraries?

==== To Existing Extensions ====
Will existing extensions be affected?

==== To SAPIs ====
Describe the impact to CLI, Development web server, embedded PHP etc.

===== Open Issues =====
Make sure there are no open issues when the vote starts!

===== Future Scope =====
This section should outline areas that you are not planning to work on in the scope of this RFC, but that might be iterated upon in the future by yourself or another contributor.

This helps with long-term planning and ensuring this RFC does not prevent future work.

===== Voting Choices =====
Pick a title that reflects the concrete choice people will vote on. 

Please consult [[https://github.com/php/policies/blob/main/feature-proposals.rst#voting-phase|the php/policies repository]] for the current voting guidelines.

----

Primary Vote requiring a 2/3 majority to accept the RFC:

<doodle title="Implement $feature as outlined in the RFC?" voteType="single" closed="true" closeon="2026-01-01T15:30:00Z">
   * Yes
   * No
   * Abstain
</doodle>

===== Patches and Tests =====
Links to proof of concept PR.

If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.

===== Implementation =====
After the RFC is implemented, this section should contain:
  - the version(s) it was merged into
  - a link to the git commit(s)
  - a link to the PHP manual entry for the feature

===== References =====
Links to external references, discussions, or RFCs.

===== Rejected Features =====
Keep this updated with features that were discussed on the mail lists.

===== Changelog =====
If there are major changes to the initial proposal, please include a short summary with a date or a link to the mailing list announcement here, as not everyone has access to the wikis' version history.
Page Tools
