Re: [Pre-RFC] Pure-code source files via .phpc extension

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.