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

Le 16/07/2026 à 00:23, Rowan Tommins [IMSoP] a écrit :
> On 15 July 2026 19:17:43 BST, "Paul M. Jones" <[email protected]> wrote:
>
>> I can see why some might think that; even so, it is still a valuable addition (however small) even if the old behavior is never removed, in the same way that strict_types is valuable even though the old behavior has not been removed.
>
> I'm going to bang this drum again: neither mode of strict_types is older than the other. Both were designed at the same time, when scalar type declarations were added to the language, and the directive was to let users choose between two competing designs.
>
> In hindsight, both the name of the directive, and the details of "mode 0", really needed more polish. Unfortunately, by then everyone was exhausted by several thousand emails arguing about the topic, and relieved that any sort of consensus had been reached.
>
> That's why I'm so keen *not* to base the name and options of this feature (or any other) on the strict_types precedent.
>
> If this is truly about offering choice, name it clearly as such, and offer all three modes (global-only, current-ns-only, fallback).
>
> If the purpose is to somehow move towards removing the fallback completely, then we should explicitly work towards that goal, e.g.:
>
> - name the directive to imply future vs past, e.g. legacy_name_fallback
> - in 8.next, emit a deprecation in certain situations if neither legacy_name_fallback=1 or legacy_name_fallback=0 is set
> - in 9.0, that could become an error, but both modes still available
> - in 10.0, legacy_name_fallback=1 would become an error, and legacy_name_fallback=0 would be a no-op as it would be the default behaviour
>
> Or, as proposed several years ago, just deprecate the behaviour directly and pick a new behaviour for all code as of PHP 9.0. People will complain about finding their backslash keys, but they'll get used to it.
>
> Regards,
>
> Rowan Tommins
> [IMSoP]


I agree with the fact that "strict_namespaces" is confusing: we're not 
talking about a namespace being strict, but about a function name 
reference to fall back to global scope if called in a namespace context. 
Naming it "legacy" implies something temporary, which I both like and 
dislike (because of the old adage "there's nothing more permanent than a 
temporary solution"), which can also be confusing in some eyes.

The whole concept (aka "not falling back to global scope") is something 
I would like to see too, because I often configure my CS fixers to 
either prepend the "\" for all function/const calls, or add "use const" 
and "use function" statements on top of the file. CS fixers could detect 
this quite easily in an AST: either the function is fully-qualified 
(then the fixer does nothing), and if it's not, rely on either "add root 
ns" or "add use stmt on top of the file" to fix it. It's already the 
case today, and in the future, it could include a third option "add 
declare stmt" to ensure no fallback is ever used anyway.

I would be picky on the naming, and maybe suggest something like 
"disable_root_ns_fallback=0|1"  ?