Le 05/06/2026 à 09:04, Alexandru Pătrănescu a écrit :
On Fri, Jun 5, 2026 at 9:07 AM Casper Langemeijer
langemeijer@php.net wrote:I think this adds a lot of complexity, for dubious benefit: not having to start PHP code files with "<?php". Question - what is the performance hit of scanning the file for <?php and, if none are found, restarting the parse process in code mode? If the hit isn't significant, this might be a way forward. There is the BC break that files fed through the parser with nothing to parse will start creating errors, but that situation (a php file with no <?php at all) feels like an error state anyway.As most projects use dynamic autoloading you'd have to add a stat call for a second filename, to try both .php and .phpc files. The performance hit for that is much bigger than any minuscule gain.I would expect that most projects in production are using composer,
and that they are using the optimized autoloader when installing in
production.
That builds a class map to exact file, and no stat call is done.
I would say this is a problem that can be solved at autoloader level,
and I recall I did a similar implementation with what composer does,
10+ years ago, when not yet using composer.--
Alex
A language-level syntax that is only available when you actually
implement it yourself in autoload, and that is provided by composer,
isn't a language-level syntax. It's one of the numerous critics of the
current partly-erased generics RFC, and I think having a feature opt-in
is nice, but opt-in-with-custom-autoload-implem isn't good.
Right now I'm working on a legacy codebase that doesn't use Composer.
Won't be able to use that unless I customize the autoload by myself, or
if I copy-paste some code from Composer itself, or from any other
implementation. Doesn't seem like a language improvement IMO.