I implemented a PR for this if you wanted to know how this will work and how edge cases will be handled. https://github.com/php/php-src/pull/4951
> I was assuming that the ultimate goal was to remove (after deprecation) the > fallback to global namespace. > In that regard, the `use function *` declaration (or whatever variation of > that) is both a way to programmer to say the preferred semantics regarding > not-fully-qualified function names, and a tool to let most legacy scripts > survive without too much effort. Deprecations aren't part of this proposal - anyone who wants to can create follow-up proposals. My proposal is different from https://wiki.php.net/rfc/fallback-to-root-scope-deprecation (it wouldn't prevent someone else from doing that or something similar, later) My goal is a feature that can start being used in php 8.0 with no breaking changes - If implemented, the other RFC would probably have to be a deprecation in 8.x, and change in behavior in 9.0 > Re: Benjamin Eberlei > If this is a valid justification, perhaps we should do the opposite of the > "deprecate fallback to global scope" RFC you mentioned, and make the "use > function *" behaviour the default in some future version. The "deprecate fallback to global scope" is doing exactly what you're proposing. it's deprecating the runtime checking \MyNS\CONST_NAME, not \CONST_NAME > Re: Rowan Tommins > That still doesn't really explain what's happening, because in code that > doesn't use any namespaced functions, the line has no user-visible effect > at all - functions are *always* used from the global namespace. What it > actually does is switch *off* a language feature, so perhaps it should be > something more like: > > declare(lookup_functions_in_current_namespace=false); It does have some impact on the user: - In a large codebase with 'use function *' in a given file, the user can now be certain that is_string() is actually the global function in code and tests, instead of mostly certain. - The code has slightly better performance I considered declare(), and could include that as a voting option for an RFC. Explanations of what this does would be available as docs on php.net if this was merged. Some parts of syntax are bound to be non-obvious to people learning any language (e.g. "use function is_string" is useful, "use is_string" isn't.) My reasons for this syntax instead of that are: - This syntax can go in one block of code, instead of separated by dozens of lines: <?php declare(strict_types=1); // dozens of lines of class uses, file comments, etc. use function otherns\my_function; use function *; - There are no per-namespace declare() directives right now, for code with multiple namespace blocks > Re: Rowan Tommins > An opt-in mechanism is certainly easier to migrate to, but it would be a > shame if every PHP file in 10 years time included a line like this: > > use function *; // don't know what this does, > but apparently it's good for performance ¯\_(ツ)_/¯ I'm not sure what assumptions you're making about php in 10 years (e.g. do you assume the other RFC will pass and this would become a no-op) Deprecating unqualified function/constant uses could/should be added independently of my proposal, and anyone who resume the other rfc could. ( https://wiki.php.net/rfc/fallback-to-root-scope-deprecation ) - From the discussion on the other RFC, I didn't get the impression it'd get enough votes because of the RFC break. - To make upgrading to 8.0 easier, it's probably make sense to deprecate that in 8.1 instead. If "use function *;" still changes behavior in 10 years, then without a feature like this, if someone were to fully qualify all function calls for a library for performance, there'd be around 10 lines per file instead of 1, (automatically or manually added) which is why this was proposed. (it'd also be likely that unnecessary uses would be left in) // I think that's all of them ¯\_(ツ)_/¯ // ... use function is_float; use function is_int; use function is_string; > Re: Claude Pache > The issue indeed is that the meaning is far from self-evident. > Maybe one could use something that everyone and their mother could understand > at first reading, such as: > > use function from global namespace; They could understand that, but memorizing and typing the phrase (and possibly searching online for what phrase it was) would be less convenient, e.g. if english was a second language. Module uses, imports, etc. in most languages tend towards conciseness, and * was the most common option I've seen (in java, python. etc.). I still prefer "use function *;", but a shorter option might be (similar to C++): use/using global functions; use global consts;
