On 23 August 2024 18:32:41 BST, Ilija Tovilo <tovilo.il...@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]

Reply via email to