[RFC] Strict Namespace Resolution View as Markdown

The RFC draft I put up that seems to have fell into the lost stack might be
coupled with this. If I'm going to run that command, whatever it's called,
the namespace autoload process seems the logical place to do it to insure
it is called before the namespace is invoked the first time. Otherwise
you'll have to have this declare at the top of every file in the namespace
which could be awkward.

On Wed, Jul 15, 2026 at 5:14 AM Rowan Tommins [IMSoP] imsop.php@rwec.co.uk
wrote:

Hi all,

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.

I said this already on the other thread, but if we're going to do this,
please let's come up with a better name.

"Strict" implies some extra check that namespaces are "correct" in some
way, which isn't really what this is about. And without reading the manual
(or RFC), I would genuinely have no idea if setting this to "1" meant "all
namespaced names have to be qualified" or "all global names have to be
qualified".

There's also at least two prior RFCs on this subject which we should look
back at:

• https://wiki.php.net/rfc/fallback-to-root-scope-deprecation - 2017;
  proposed removing the fallback completely; discussed but never voted
• https://wiki.php.net/rfc/use_global_elements - 2020; proposed a declare
  for global-only lookups; Declined

There are probably other relevant threads in the list archives as well.

Regards,

Rowan Tommins
[IMSoP]

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.

I know it won't change anyone's mind, but for the record, I've always found this baffling. Adding a single punctuation mark next to function calls seems far more readable to me than having a huge block of "use function" lines at the top of every file.

The often-suggested "scalar methods" would add more punctuation than moving to "no global fallback" - "\strlen($foo)" vs "$foo->length()".

Rowan Tommins
[IMSoP]

Hi Ilia,

Hi Paul

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.

I sympathize with that rejection -- I don't especially like prefixing everything with \ myself. Even having to import every global function explicitly, as required under some coding stndards rulesets, feels noisy to me at times.

But to be clear, declare(strict_namespace=1) is an opt-in behavior. If you want the global fallback behavior, no need to declare the directive. Further, I would not advise "forcing" anyone to use it who doesn't want it.

Have I maybe missed what you were getting at?

-- pmj

Hi

• The rules for classes, functions and constants are equivalent.

Agreed.

• The default is short / easy to type.

Agreed, but I'm probably drawing a different conclusion than you, see
below.

• The rules are consistent inside and outside namespaces.

Agreed.

• There is no fallback.

Agreed.

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.

I believe that “unqualified names are relative” is both an obvious, and
a pragmatic choice. Given that a majority of class-based code is
namespaced, global classes are rarely used, whereas it's often the case
that related classes from the same namespace are required. An obvious
example would be exception classes, which are colocated within the same
namespaces under the Throwable policy of PHP.

• 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.

While this is true today for large parts of PHP’s standard library, our
policy strongly recommends the use of namespaces for “new components”
and this includes functions and constants. The new DOM API in PHP 8.4
aliased many of the global constants into the Dom\* namespace, and
there's also Dom\import_simplexml(). Similarly, I'm expecting that the
new date and time API will include some functions in addition to the
OO-API and these would also be put into the Time\* namespace. One
example I can think of would be a Time\now(): Instant function for
easy retrieval of an instant from the system clock. Ideas for a new
iterable-API also suggested the use of a iterable\* namespace, e.g.
iterable\map() (for array_map()) or iterable\filter() (for
array_filter()).

Thus PHP developers already need to be prepared to explicitly import or
fully-qualify function calls and any change we're making should be
reasonably “forward looking” with regard to how the standard library is
going to be modernized.

Best regards
Tim Düsterhus

Primary pushback thus far has not been on the functionality per se but on the directive name itself. The currently-suggested equivalent alternatives are:

strict_namespace=1            (RFC as-is)
legacy_name_fallback=0        (R. Tommins)
global_fallback=0             (T. Düsterhus)
disable_root_ns_fallback=1    (A. Rock)

Of those, I'd be OK with global_fallback=0 (though I do still prefer strict_namespace=1).

Are there any further suggestions or objections on this point?

Hi Paul,

Thank you for working on this RFC! It's essentially the same as my declare(root_fallback=0) idea from 2019. 1

I think the global_fallback=0 alternative from Tim indicates the resulting behavior most clearly, but I don't have a strong preference between this and strict_namespace=1.

-Theodore

Am 17.07.2026, 20:39:00 schrieb Paul M. Jones pmjones@pmjones.io:

Hi all,

Primary pushback thus far has not been on the functionality per se but on
the directive name itself. The currently-suggested equivalent alternatives
are:

strict_namespace=1            (RFC as-is)
legacy_name_fallback=0        (R. Tommins)
global_fallback=0             (T. Düsterhus)
disable_root_ns_fallback=1    (A. Rock)

Of those, I'd be OK with global_fallback=0 (though I do still prefer
strict_namespace=1).

In my opinion it makes sense to vote on the concept and then have a
secondary vote on the name.

I‘d argue everyone agrees we need this but with only one option it might
fail.

Are there any further suggestions or objections on this point?

-- pmj