Hi Bob, (Sorry for the very long delay on this reply.)
> On Jun 16, 2026, at 17:22, Bob Weinand <[email protected]> wrote: > > What is the motivation to not do a second call to the function autoloaders > with "bar" (global namespace) when "bar()" is being called in the Foo > namespace and the initial call with "Foo\bar" doesn't resolve to anything? If I understand your question and the engine itself correctly: The function autoloader only fires *after* the name resolution has occurred and no global fallback has been found. That final resolution of the name (the global one) is the only one that *can* be passed to the autoloader at that point. The original namespaced name just isn't available. That is: the resolver looks for the namespaced function, sees it is not defined, looks for a global name to fall back to, *that* one isn't defined, and then an error gets raised; the function autoloader kicks in at the moment the error would have been raised. As far as I can tell, to get access to the original namespaced name, the implementation would have to hook into the name resolution logic, and that carries a more substantial set of troubles. Cf. these notes from years ago: - S. Malyshev, 2013: https://externals.io/message/68693 - N. Popov, 2016: https://externals.io/message/94533 and https://externals.io/message/94897 - T. Brown, 2019: https://externals.io/message/105757 It looks like putting function autoloading the name resolution logic is huge a performance drag. > That would probably have much less rough edges, completely sidestepping the > issue here with Foo\bar() not being found. There is the possibility of something like `declare(strict_namespace=1)` to avoid the global fallback entirely, which would give the autoloader the namespaced function name instead of the global one. (This is pretty much what Brown suggests above.) Do you feel that's a viable path forward? -- pmj
