> On 23 Aug 2024, at 15:08, Nick Lockheart <li...@ageofdream.com> wrote: > > A third option, which I haven't seen come up on the list yet, is that > unqualified functions that are PHP built-ins are treated as global, and > using a function having the same name as a built-in, in a namespace > scope, requires a fully qualified name to override the built-in. > > It seems that if someone is writing `array_key_exists()` or similar > they probably mean the built-in function, and in the rare cases where > they do mean `\foo\array_key_exists()`, they can write it explicitly. > > Functions that are *not* on the built-in function list could default to > the local namespace.
This doesn't solve the "future hidden BC break" aspect, at all. If I write a namespaced function `http_parse_url` to adhere more strictly to whatever relevant RFC, when I write it, it will work as expected using a relative name (and/or itself quite likely using helper functions in the same namespace) If an RFC then approves a "core" `http_parse_url` function to serve as a better replacement for the old `parse_url`, suddenly my function won't work the same way with the new version of PHP... because of a global function that didn't exist when I wrote mine. If this "global first" change is made, *any* use of unqualified functions that refer to the current namespace will *have* to use some form of current-namespace indicator to be future version-safe. If you want to make global functions resolve without a `\` the only realistically safe solution is to completely remove unqualified lookup of local function (and constant) symbols, and force them to always use a name that resolves absolutely, because otherwise any future version could break what they do completely.
