Hi Tim, > On Jun 20, 2026, at 08:14, Tim Düsterhus <[email protected]> wrote: > > Hi > > Am 2026-06-17 16:47, schrieb Rowan Tommins [IMSoP]: > >> 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. As we know, it's caused by the namespace resolution rules, and I'd rather not take those on directly; the strict_namespace declaration might help to soothe it. Speaking of which: > 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? -- pmj
