On Mon, Nov 10, 2025, at 20:19, Rob Landers wrote:
>
>
> On Sun, Nov 9, 2025, at 22:32, Rob Landers wrote:
>>
>>
>> On Sun, Nov 9, 2025, at 21:51, Tim Düsterhus wrote:
>>> For this one I am however not sure if it ticks the “composes well”
>>> checkbox - that greatly depends on the syntax choice and how modules
>>> will look like if/when they eventually arrive.
>>
>> I understand the concern. Composability matters a lot, especially for
>> features that touch visibility. My goal with this RFC is to take a boundary
>> PHP already has (the lexical namespace) and make it enforceable without
>> needing to answer the bigger "what’s a module/package?" question first.
>>
>> Right now, different people in the ecosystem use namespaces in different
>> ways: some treat them as hierarchical, some as flat prefixes, some map them
>> to directory trees, some don’t. Trying to define prefix rules,
>> upward/downward access, or package-like confinement gets us right back into
>> the same conversation we’ve been stuck on. That’s why this RFC deliberately
>> picks the simplest rule PHP could enforce today: exact namespace equality.
>>
>> If a future RFC defines modules/packages, namespace-visibility can either:
>> - fold into that boundary,
>> - be superseded by it, or
>> - be used inside it (e.g. `internal` for modules, `private(namespace)`
>> within module internals).
>>
>> Nothing in this RFC makes that harder.
>>
>>>
>>> Your RFC appears to use the old template for the “RFC Impact” section
>>> which doesn't yet include the “Ecosystem Impact” subsection, but
>>> indicating that “significant OPcache changes” are required makes me
>>> wonder about the cost-benefit ratio.
>>
>> Thanks! I’ll look at the new template and call out ecosystem impact (this
>> was originally written back in April/May?). On the OPcache point:
>> "significant" is probably overstating it. The change is limited to
>> persisting one additional interned string on zend_op_array and refcounting
>> it correctly. The cost is paid at compile time, not at call time, so runtime
>> performance impact should be negligible. I’ll reword this to be more precise.
>>
>>>
>>> > Aviz establishes `visibility(operation)` as the pattern for asymmetric
>>> > visibility, where the keyword controls the caller set and parentheses
>>> > restrict the operation (get/set). That’s why `private(namespace)(set)`
>>> > follows the same rule: the base visibility is still "private", and the
>>> > parentheses narrows who may call it.
>>> >
>>> > If we introduced a standalone keyword like `internal` or `nsviz`, we’d
>>> > effectively be adding a new visibility class, not a refinement of
>>> > `private` and would bring its own semantics, collision issues, and
>>> > interactions with any future module work. This RFC aims to minimise
>>> > surface area, which is why it treats namespace visibility as a refinement.
>>>
>>> As noted in my reply in the thread from Faizan, calling this a
>>> refinement of `private` is not really accurate / doesn't work in practice.
>>
>> Agreed. After the discussion with you, Alex, and Larray, I think it's
>> clearer to describe `private(namespace)` as a distinct caller-set, not a
>> subset of protected or private. I’ll update the RFC text to reflect that and
>> disallow weird combinations (to be more clearly defined in the RFC).
>>
>>>
>>> > If the community prefers prefix-based visibility or package-level
>>> > visibility, that could be explored in a follow-up RFC. I’m not opposed to
>>> > more expressive forms; I’m just not binding this RFC to a package model
>>> > the language hasn’t defined yet.
>>>
>>> To do so, the syntax would need to account for that. I have not yet seen
>>> a good proposal for that that doesn't end up as “symbol soup” that
>>> doesn't really fit the existing language syntactically.
>>
>> My earliest version simply used `namespace`:
>>
>> class P {
>> namespace function x() {}
>> }
>>
>> It might make sense to return to that syntax if people don’t like the
>> current syntax. I don’t have a strong attachment to the exact spelling, what
>> matters is the semantics.
>>
>> — Rob
>
> I’ve updated the RFC and the implementation with some significant
> clarifications and corrections:
> • *Inheritance semantics now follow `protected` rather than `private`*
> `private(namespace)` members are inherited and must follow normal
> signature-compatibility rules.
> Visibility is enforced based on the declaring namespace rather than the
> inheritance hierarchy.
> • *Incompatible redeclarations are now clearly defined*
> Transitions between `protected` and `private(namespace)` are disallowed in
> either direction.
> This avoids unsound cases where substitutability would be broken for callers
> in the declaring namespace.
> • *Asymmetric visibility rules clarified*
> `protected` and `private(namespace)` operate on different axes (inheritance
> vs namespace), so mixed AViz like
> `protected private(namespace)(set)` is now a compile-time error.
> • *Expanded examples and error messages*
> The RFC now includes clearer examples of the invalid cases, inheritance
> rules, and AViz combinations.
> • *Syntax moved to an explicit open issue*
> Because the semantics now line up with `protected` rather than `private`, the
> spelling `private(namespace)` may not be ideal.
> I’ve listed this in the “Open Issues” section and I'll include some
> previously considered alternatives that preserve the semantics here:
> • `namespace function x() {}`
> • `local function x() {}`
> • `private:ns function x() {}`
> • `protected:ns function x() {}`
> My personal preference is toward the simpler forms (`namespace` or `local`),
> but I’d like to collect feedback before changing the RFC text.
>
> Updated RFC:
> https://wiki.php.net/rfc/namespace_visibility
> <https://wiki.php.net/rfc/namespace_visibility?utm_source=chatgpt.com>
>
> Implementation:
> https://github.com/php/php-src/pull/20421
>
> Thanks to everyone who pointed out the inheritance edge cases; those surfaced
> issues that needed to be addressed. Further feedback is welcome.
>
> — Rob
On my commute, I was exploring the syntax further and the feedback I've gotten
so far. Specifically:
class A {
local function x() {}
}
This is accssible only with the exact same namespace where it is declared (this
RFC). I was reminded that this is very similar to "file private" but allows the
boundary to extend across multiple files in the same namespace.
Then, we could have this in a followup RFC (which I've already started
drafting) that doesn't actually require `local` but provides a broader
"package-like" scope without requiring PHP to define what a package is.
class A {
namespace function x() {}
}
This would be accessible within the namespace it is declared, as well as parent
and child namespaces (thus we don't make any assumptions about hierarchy).
Using the following namespace structure:
App\
├── Auth\
│ ├── SessionManager (declares namespace function validateToken())
│ ├── OAuth\
│ │ └── OAuthProvider
│ └── Session\
│ └── SessionStore
├── Billing\
│ └── PaymentProcessor
└── Controllers\
└── LoginController
The following can access `validateToken()` :
- App\Auth\* (So, SessionStore/OAuthProvider)
- App\* (parent namespace)
But the following cannot access it:
- App\Billing\*
- App\Controllers\*
- \ (global namespace)
The global namespace is a special case where `namespace` and `local` behave
exactly the same.
Before rewriting the RFC around this, I'd like to guage whether people feel
like the keyword based approach is a clearer direction than
`private(namespace)`.
— Rob
