> This would be a compile error right now though, because we don't allow "use"d > symbols and declarations to clash.
As I surprisingly discovered when implementing the RFC, they don't clash. The PHP interpreter has a special case where it doesn't warn or throw about the name being in use if the resolved (namespaced) name in use is the same as the element being declared. See https://3v4l.org/RtPKv - the below example works. ``` <?php namespace NS; use function NS\foo; use const NS\BAR; function foo() { echo BAR; } const BAR = 3; foo(); ``` > While I was the one who originally suggested to allow this kind of code, > I think it might be better to just unconditionally make it a compile error, > and require the use of declare(function_and_const_lookup='default') > if you want to declare namespaced constants or functions. >The main motivation for allowing it is interoperability with namespace-scoped >declares, > but as those don't exist yet (and would still allow a per-file opt-out), we > can delay this issue. > > I think that principally, the correct behavior here is to bring the symbol > into scope as it is declared, > but as you already pointed out, this leads to unclear semantics when > conditional function declarations are involved. The subset of code that can be written requiring "use function NS\foo;" and "use function NS\MY_CONST;" with function_and_const_lookup='default' is larger than forbidding it completely, while still avoiding ambiguity. > As a minor note, rather than using 'default' as one of the values, > I think it would be better to use 'fallback' to make it robust against a > potential future change of defaults. I'd rather have that done when the future change of defaults is being proposed. Supporting 'fallback' might cause confusion and extra work if the name resolution defaults ever change in a different way. At the point where they do change, we either do or don't want a way to support the old 'fallback', but we will want to support the new 'default'. Right now, it's deliberately intended to be the same as just leaving the setting off for that file. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
