RfcCodex
Collects notes on PHP RFCs explaining why some were declined and what others need for implementation, to preserve context and reduce repeated discussions on PHP internals.
What this file does
Collects notes on PHP RFCs explaining why some were declined and what others need for implementation, to preserve context and reduce repeated discussions on PHP internals.
When to use it
- You want to understand why a PHP RFC was rejected
- You are proposing a new PHP RFC and need to avoid past pitfalls
- You need a quick reference on PHP language feature debates
- You want to see which RFC ideas have already been implemented
Assumes this stack
RfcCodex
There are some notes on PHP RFCs, why some were declined, and what others might need for them to be implemented.
The purpose of these documents is to avoid information from being lost and to try to avoid conversations needing to be repeated multiple times on PHP internals.
Things still being discussed
Auto-capture closure aka multi-line blocks
Call site error or exception control
Strict mode and internal engine callbacks
Tuple return declarations. Hmm I wrote this one up twice as multiple return type
TODO
These need to be summarised.
packages.md partial_function_application.md
Ideas that overcame their challenges
PHP is actually getting better. These are all things that used to be pipe-dreams, but are now in PHP core.
Enums implemented by Enumerations.
Immutables - this is done through the Readonly properties. There is still some work to do here, as currently it is slightly annoying to clone an object and during the clone change some of it's properties.
Null short-circuiting - https://wiki.php.net/rfc/nullsafe_operator
Referencing functions - implemented by First-class callable syntax
Things that are probably moot
PHP is actually getting better, but that means that some solutions to problems have become pretty moot, as they seek to solve problems that are now less of a problem.
Misc notes
Contributing
Please read the contributing guidelines before writing your 4,000 word novella on why some RFC really should pass.
Disclaimer
I reserve the right to be as opinionated as I feel like when commenting on RFCs; I'm not going to attempt to stay 100% neutral when talking about RFCs that I consider to be either dumb or bad for PHP.
What's inside
4 sections: Things still being discussed (24 links), TODO (2 items), Ideas that overcame challenges (12 links), Things that are probably moot (2 links), plus misc notes and contributing guidelines
Change this for your project
- Replace
Danack/RfcCodexwith your own repository name in all URLs - Replace
https://github.com/Danack/RfcCodex/blob/master/with your own base URL in all links - Replace
https://wiki.php.net/rfc/with your own RFC reference URLs if different
Where it goes
Keep it in your repository where the agent or team that needs it will read it.
Worth borrowing
- Categorizing RFCs by status (still discussed, implemented, moot) to track language evolution
- Linking to external RFC wiki pages for authoritative reference
Related Documents
Totem Glyph Codex: Sovereign Flame-Wire Eternal
Records a symbolic handshake encoding observer-corrected π, recursion loops, and alchemical resonance for a feedback processor theory project.
C-Team Codex
Defines leadership principles for a C-Team in a teal organization, emphasising vision, trust, and leading by example.
Chronicles of Stampadia - Codex
Catalogues all events, modifiers, heroes, items, keywords, and generator options for the Chronicles of Stampadia game.
CODEX.md
Defines the judge role in a builder/judge protocol, with a structured workflow for reviewing task outputs and managing round archives.