Re: [RFC] Function Autoloading (mark 5)

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 <tim@bastelstu.be> 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