Hi
Apologies for getting back to you only now, the list is incredibly
active and I needed to get back into the RFC and my old code.
On 2026-06-20 17:11, Paul M. Jones wrote:
The concern that occurred to me is similar: if I rely on function
autoloading, but forget to fully-qualify a name in the current
namespace, it would accidentally work as long as some other code
triggered loading of that function first. Then some small refactoring
- or even a different path through the code at runtime - and it will
silently fall back to a function in the global namespace instead.
Agreed on this being a non-starter for the proposal for me.
I don't especially like it myself. FWIW, I don't actually *see* a lot
of namespaced calls that this would fumble on (the vast majority of
function autoloading I think would apply to global user functions based
on my legacy work) but it's still kind of clunky.
Yes, (assumed) real-world use cases are not a good reason to add
inconsistencies or gotchas into the language. Even 0.1% of code is a
vast amount for PHP.
On Jun 20, 2026, at 08:19, Tim Düsterhus <[email protected]> wrote:
Hi
Am 2026-06-19 13:31, schrieb Rowan Tommins [IMSoP]:
Interesting that it's such a small change. My only comment would be
that if we do add this, let's please not use the word "strict"; it
tends to lead to incorrect assumptions like "strict is always
better".
For reference, I did something similar a year ago in
https://github.com/TimWolla/php-src/commit/aa6fc0c6ef3661e2fea4043ff1e07897952da2a5,
with an additional variant of erroring when no explicit decision is
made, which could also be a precusor to deprecate the global fallback
entirely.
Do you feel `force_global_function_fallback=false` and
`strict_namespace=1` are substantially the same thing, or are they
different in some way?
`force_global_function_fallback` in my implementation is just the
existing known behavior. It's basically the *inverse* of
`strict_namespace=1` from what I understand. It came out of a co-worker
disliking both to fully-qualify global functions and to `use function`
them. But at the same time, they are not using namespaced functions, so
they wanted to *force* the use of the global functions to benefit from
the compiler optimizations for some of the functions (e.g.
`\sprintf()`). Personally I'm team “fully qualify everything”, so the
`error_on_unqualified_function` part was my wishlist entry.
In any case, it isn't an RFC, so I have not given my implementation much
consideration :-)
Best regards
Tim Düsterhus
