Re: [PHP-DEV] [RFC] Strict Namespace Resolution

[email protected] (Ilija Tovilo) Wed, 15 Jul 2026 17:54:04 +0200
Newsgroups php.internals
Message-ID <[email protected]>
Hi Paul

On 15.07.26 02:54, Paul M. Jones wrote:
> Per feedback from Tim Tim Düsterhus<https://externals.io/message/131332#131899> I have extracted the `declare(strict_namespace=1)` portion of the function autoloading proposal to its own RFC.
>
> - RFC:https://wiki.php.net/rfc/strict-namespace
> - PR:https://github.com/php/php-src/pull/22736
>
> (This RFC is an aid to, but not strictly required for, function autoloading.)

This flag forces the use of a \ prefix, but it's worth noting there are 
some communities (e.g. Laravel and Symfony) who have explicitly rejected 
the idea of prefixing all functions for readability reasons. We can 
force them into conforming, or forever keep the old behavior, but that's 
probably not the best approach.

If PHP were designed today, what I would personally like is:

  * The rules for classes, functions and constants are equivalent.
  * The default is short / easy to type.
  * The rules are consistent inside and outside namespaces.
  * There is no fallback.

In practice, this would mean pretty much the opposite of this proposal:

  * `new Foo`/foo()/FOO always refers to the global symbol. If you want
    the local symbol, add a local use like for everything else.
  * The only conceivable exception could be a local
    class/function/constant declaration within the same file, which
    could conceptually add a use for you.
  * Global function calls (which is the vast majority of all function
    calls) can remain unprefixed, and references to global classes no
    longer need a prefix.
  * Class names behave equivalently inside and outside namespaces.
  * The lack of a fallback solves ambiguity issue that prevents many
    optimizations (https://externals.io/message/124718).

I'm not sure if there's a world where we can still move into that 
direction, e.g. via a declare as a migration path.

Ilija