New RFC Proposes Opt-in Namespace Fallback Directive for PHP

Paul M. Jones has split the `declare(strict_namespace=1)` mechanism from the function autoloading RFC into a standalone proposal. The directive would let code opt out of PHP's global fallback for unqualified function and constant names inside namespaces. It is meant to mitigate the rare 'shadow global' case in function autoloading, but internals members are debating the directive's name and whether it delivers enough value without deprecating the old behavior.

Paul M. Jones has extracted the `declare(strict_namespace=1)` concept from the function autoloading RFC into a standalone proposal titled "Strict Namespace Resolution". The RFC is available at https://wiki.php.net/rfc/strict-namespace and is accompanied by pull request https://github.com/php/php-src/pull/22736. The mechanism is intended as an aid to, but not a strict requirement for, the broader function autoloading initiative.

The directive would allow developers to opt out of PHP's existing fallback behavior, where an unqualified function or constant name inside a namespace is searched first in the current namespace and then, if not found, in the global namespace. With `declare(strict_namespace=1)` active, such references would resolve only within the declared namespace, effectively requiring explicit imports or fully-qualified names for global symbols.

Discussion on the PHP internals list has focused heavily on naming and scope. Rowan Tommins argued that the label "strict_namespace" is misleading because the directive does not validate namespace correctness; he suggested alternatives such as `legacy_name_fallback` or offering three explicit modes (global-only, current-namespace-only, fallback). Tim Düsterhus proposed `declare(global_fallback=0)` as a clearer option, while Alex Rock floated `disable_root_ns_fallback=0|1`.

Ilija Tovilo questioned the overall value of the proposal if the legacy fallback is never removed or deprecated, noting that users who opt in gain nothing they could not already enforce with a linter. He also sketched an alternative design in which unqualified names always refer to the global symbol, with local symbols accessed via explicit `use` imports. Paul M. Jones responded that the primary driver remains mitigating the rare "shadow global" case in function autoloading, and that the directive is intentionally optional.

Michael Morris raised a practical concern about applying the directive across many files without requiring it at the top of every file, which Rowan Tommins described as a deeper "native package" or "module" design problem that goes beyond autoloading. Tim Düsterhus also noted that static analyzers and IDEs would need to recognize the directive to provide diagnostics.

References to prior RFCs on the same topic were also raised: "Fallback to root scope deprecation" from 2017, which was discussed but never voted on, and "use_global_elements" from 2020, which was declined.