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]
