Re: RFC: short and inner classes

On 25 March 2025 20:29:16 GMT, Rob Landers <rob@bottled.codes> wrote: > Personally, I'd feel that file-private should be kept as simple as possible and limit it > to "top-level" things, but that doesn't necessarily have to be the case. If we did > allow it on methods/properties, when mixing it with regular visibility, what happens? > fileprivate public private(set) ... means what exactly? If we didn't have "protected", would you ask the same about "protected private"? "fileprivate" would be just another access level, not something you'd combine with existing ones. > maybe fileprivate on a property means > public in the file, but private > outside the file. But then how would that intersect with inheritance? That was the point of my philosophical rambling about Swift: you don't have to define new access levels in relation to old ones, or new features as exceptions to old definitions. You can just define the keywords you allow, and the access they provide. That's true whether you're defining "private", "fileprivate", or "access_level_42". For instance, "fileprivate" could simply mean "accessible from any code defined in this file". Since classes are fully declared in one file, that makes it a strict superset of the access currently meant by "private", and applies equally well to a whole type, a method, or a property. I see no reason for inheritance to be involved at all. If we want an access level that means "accessible from any code in this file, or any subclass of the current type", we can make up a keyword for that as well - "fileprotected", or "fileprivate_or_protected", or whatever. Rowan Tommins [IMSoP]