[swift-evolution] [Discussion] A Problem With SE-0025?

[Matthew Johnson]

> On Jun 16, 2016, at 8:27 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> 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.

Thanks, this makes your argument more clear.  To summarize, you believe there should be an utterable access modifier corresponding to all possible levels of visibility (and you prefer to do that without introducing a 5th access modifier), correct?

This requires changing semantics of `fileprivate` (or introducing a new access modifier) which is not in scope for SE-0025.  It is not just a rename of the old `private` which was in scope for SE-0025.  I believe this means it would require a new proposal (of course the core team is the final arbiter of that).  

The community should have a discussion and review regarding whether to adopt your suggested semantic change or not.  Do you disagree?

> 
> 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
>