Hi Rob On Thu, Mar 13, 2025 at 12:01 PM Tim Düsterhus <t...@bastelstu.be> wrote: > > Am 2025-03-12 11:10, schrieb Rob Landers: > > - Accessing inner classes is done via a new token: ":>" instead of > > "::". > > I don't particularly like that. It is “invented syntax” and I don't > think that inner classes are sufficiently valuable to dedicate an entire > operator to them
I would like to echo these thoughts. I also think the RFC is kind of missing the mark. Arguably the most common use-case for `@internal` is to restrict a class to a specific package/module or namespace, regardless of the user's class hierarchy. I believe you specifically call this a non-goal: > Currently, many libraries implement “internal” classes by using a naming > convention or an @internal annotation in the docblock. Inner classes enable > libraries to define an internal class that cannot be used outside the class > it is defined inside. This feature is not meant to be used as a “module” > system, but rather as a way to encapsulate logic internal to a class, such as > DTOs or helper classes. At least if I understand this statement correctly. In that case, I see much less value in nested classes. They might still be ok if they are extremely simple, but the proposal is currently quite complex. It has a custom operator, it deals with shadowing, LSP, runtime resolution and more, in addition to visibility which is the actual goal. Maybe more use-cases are enabled, but I don't think they are currently well described. Assuming visibility can partially be implemented in a simpler way (e.g. top-level, file-private classes), the costs seem to outweigh the benefits in my opinion. Hence I would not be in favor of the RFC in this or a similar form. Ilija
