Re: [Concept] Flip relative function lookup order (global, then local)

> On 23 Aug 2024, at 15:08, Nick Lockheart <lists@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.