> I am not convinced this is necessary. If there *is* a containing 'private'
> scope you can just leave the member unannotated to get this behavior. If
> there isn't you can use 'fileprivate' as it is already defined. Why is that
> not sufficient?
Here's what's making me think about this: In our current generated interfaces,
we mark every symbol with an access modifier (except for protocol requirements,
which cannot take access modifiers). This is because every kind of visibility
*has* an associated access modifier. They are all utterable, and this makes
everything clearer, because when you want to be explicit you can always write
it out.
I don't like the idea of introducing unutterable access control levels, or
marking things with confusingly broad-seeming access modifiers, or complicating
the access control model with artificial levels. On those axes, I would score
the various options as:
Worst: Having an extra, unutterable access modifier that floats
relative to the other access levels.
Awful: Having an extra access modifiers that floats relative to the
other access levels, but has a name (like `default`).
Bad: Having an extra, unutterable access modifier between `fileprivate`
and `private`.
Okay: Using `internal` whenever there's no access modifier, and not
warning if the effective scope is smaller.
Good: Having an extra access modifier between `fileprivate` and
`private`, but which has a name (like `inheritprivate`)
Better: Changing the definition of `fileprivate` to be within the
surrounding private type if there is one, without changing the keyword.
Best: Changing the definition of `fileprivate` to be within the
surrounding private type if there is one, and changing the keyword to match.
If I were implementing it, I think what I would do at this point is:
1. Implement the feature with support for private types artificially
disabled. At this point, you have provided a strict subset of what the proposal
specifies; if the implementation is good enough, that ought to be mergeable.
2. Create a new branch from that commit which implements the change to
`fileprivate`'s semantics I described. This is a highly plausible way to fill
the gap in the proposal, and exploring it seems like a sensible option.
3. Leave the keyword alone; that's up to the core team to change.
Of course, I'm *not* implementing it; Robert Widmann is. So I think that for
step 2 he should implement whichever solution he thinks is best, or if he's
worried about wasting work, simply pause at that point and wait for core team
input.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
