Re: [PHP-DEV] [RFC] Strict Namespace Resolution

Hi

On 2026-07-15 17:54, Ilija Tovilo wrote:
>  * The rules for classes, functions and constants are equivalent.

Agreed.

>  * The default is short / easy to type.

Agreed, but I'm probably drawing a different conclusion than you, see 
below.

>  * The rules are consistent inside and outside namespaces.

Agreed.

>  * There is no fallback.

Agreed.

> In practice, this would mean pretty much the opposite of this proposal:
> 
>  * `new Foo`/foo()/FOO always refers to the global symbol. If you want
>    the local symbol, add a local use like for everything else.

I believe that “unqualified names are relative” is both an obvious, and 
a pragmatic choice. Given that a majority of class-based code is 
namespaced, global classes are rarely used, whereas it's often the case 
that related classes from the same namespace are required. An obvious 
example would be exception classes, which are colocated within the same 
namespaces under the Throwable policy of PHP.

>  * Global function calls (which is the vast majority of all function
>    calls) can remain unprefixed, and references to global classes no
>    longer need a prefix.

While this is true today for large parts of PHP’s standard library, our 
policy strongly recommends the use of namespaces for “new components” 
and this includes functions and constants. The new DOM API in PHP 8.4 
aliased many of the global constants into the `Dom\*` namespace, and 
there's also `Dom\import_simplexml()`. Similarly, I'm expecting that the 
new date and time API will include some functions in addition to the 
OO-API and these would also be put into the `Time\*` namespace. One 
example I can think of would be a `Time\now(): Instant` function for 
easy retrieval of an instant from the system clock. Ideas for a new 
iterable-API also suggested the use of a `iterable\*` namespace, e.g. 
`iterable\map()` (for `array_map()`) or `iterable\filter()` (for 
`array_filter()`).

Thus PHP developers already need to be prepared to explicitly import or 
fully-qualify function calls and any change we're making should be 
reasonably “forward looking” with regard to how the standard library is 
going to be modernized.

Best regards
Tim Düsterhus