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

On 23 August 2024 18:32:41 BST, Ilija Tovilo <tovilo.ilija@gmail.com> wrote: >IMO, 1. is too drastic. As people have mentioned, there are tools to >automate disambiguation. But unless we gain some other benefit from >dropping the lookup entirely, why do it? I can think of a few disadvantages of "global first": - Fewer code bases will be affected, but working out which ones is harder. The easiest migration will probably be to make sure all calls to namespaced functions are fully qualified, as though it was "global only". - Even after the initial migration, users will have to watch out for new conflicting global functions. Again, this can be avoided by just pretending it's "global only". - The engine won't be able to optimise calls where the name exists locally but not globally, because a userland global function could be defined at any time. - Unlike with the current way around, there's unlikely to be a use case for shadowing a namespaced name with a global one; it will just be a gotcha that trips people up occasionally. None of these seem like showstoppers to me, but since we can so easily go one step further to "global only", and avoid them, why wouldn't we? Your answer to that seems to be that you think "global only" is a bigger BC break, but I wonder how much difference it really makes. As in, how many codebases are using unqualified calls to reference a namespaced function, but *not* shadowing a global name? Regards, Rowan Tommins [IMSoP]