Fwd: Intended proposal for class visibility

Hey there! I'm thrilled since this is my first proposal. I'd like to propose a new visibility schema for classes, based on a explicit group of namespaces allowed to use the class. The goal of this proposal is to provide a way to cover from a native language feature what currently is usually patched using "@internal" annotations. If the visibility declaration ("internals" in this example) is present, the class could only be visible for other classes on the list of the specified namespaces. <?php namespace Vendor\Library\Feature; final class Foo implements Vendor\Library\InternalInterface internals Vendor\Library, Partner\VendorBridge { } /// this class will be allowed to use Vendor\Library\Feature\Foo because it is declared directly at Vendor\Library namespace <?php namespace Vendor\Library; use Vendor\Library\Feature\Foo; class Allowed { public function __construct() { new Foo(); } } /// this class will be allowed to use Vendor\Library\Feature\Foo because it one level under Vendor\Library namespace <?php namespace Vendor\Library\Service; use Vendor\Library\Feature\Foo; class Allowed { public function __construct() { new Foo(); } } /// this class will NOT be allowed to use Vendor\Library\Feature\Foo, since the current namespace Vendor doesn't match and is not under Vendor\Library nor Partner\VendorBridge. <?php namespace Vendor; use Vendor\Library\Feature\Foo; class Disallowed { public function __construct() { new Foo(); } } I think a good example of the kind of project that can leverage this feature are the libraries which expose a public API with its own implementation, but need to protect their internal classes in order to avoid them to be tied to their BC promise. Note that I really don't know how to implement this internally, or if this must be just related to the autoload mechanism instead of a (maybe) more complex compilation phase. Please, let me know if you have some concerns or doubts about it. Thank you in advance. -- Javier Spagnoletti