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" ?
