On 25 March 2025 20:29:16 GMT, Rob Landers <[email protected]> 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]