On Mon, Jan 27, 2020 at 3:43 PM tyson andre <tysonandre...@hotmail.com> wrote:
> > 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(); > ``` > Interesting :) > > 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. > Right ... well, as the above code isn't a compile-error like I expected, I guess this is fine :) > > 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. Sounds reasonable. Nikita
