[swift-evolution] Type-based ‘private’ access within a file

[Adam Knight]

On Apr 6, 2017, at 1:17 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Apr 6, 2017, at 11:10, Vladimir.S <svabox at gmail.com> wrote:
>> 
>> On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote:
>>> Hi, -evolution. I’ve said this before, but *I think this new proposal is a
>>> terrible idea*. It privileges types in a way that is damaging to the language.
>>> 
>>> [There isn't really anything new in my discussion below; everyone on-thread
>>> is smart enough to have brought up these points already. But I wanted to go
>>> on record about it, at least.]
>> 
>> Thank you for sharing your opinion regarding this subject.
>> Do I understand correctly, that *you* propose to just revert access levels and modifiers to Swift2 stage? (i.e. to drop current 'scoped-private' and rename 'fileprivate'->'private')
>> Or do you support to leave current 'scoped-private' under another name?
> 
> Neither, unfortunately. We accepted SE-0025, though I wish we hadn't; we named the two levels "private" and "fileprivate", though I wish we hadn't; and now there is lots of existing code relying on that, and it would be mean and capricious to force people to change that code when they migrated to Swift 4. I don't like where we ended up but Swift does not exist in a vacuum.

I think it neither mean nor capricious *if this is the last change we are ever going to do here*.  We need to get it right, even if there’s a breaking source change.  There’s a future-looking responsibility that is greater than the promises of minimal changes in the next version.  If we are locking ourselves in to this, then let’s fix it once and for all.  Or at least get damned close.  If ’25 was a mistake then stand up, apologize, and fix it right.

The handcuffs are effectively self-inflicted.  We can judge for ourselves if we actually need to be wearing them or if, for the greater good, we pop out of them for a moment and Do The Right Thing.

IMO, there is a case to be had for:
* Things truly private to a type (eg. a seek index that must be changed in step with buffer data and metadata)
* Things private to a set of related types in one file (eg. every case in C where you didn’t put something in the header)
* Things private to a type and extensions to it (eg. a count of characters in a string; extensions might be allowed to change this)
* Things private to a module (most everything else).
* Things others can override (subclasses, etc.).

Right now we have identifiers for most of these.  What they’re called or when we use them is for another discussion; this is one of capability and need.  The question is: does the language support clean code for all common use cases?

Lacking a proper “private” that is tightly-scoped to the type it’s defined in would make that a resounding No.  Private means private, not Private But Everyone In The Room Can See It And Also Some People Near The Window.  That’s something else.

Reading this discussion for the past few days, I get the sense that no one has really bothered to define the question properly.  What are we trying to solve, specifically?  For whom?  What does that user expect?  What are we trying to avoid? To succeed with?  I see a lot of people talking about how they use things today and want to use them tomorrow, but what is the community goal here?  Can it be stated in one or two sentences?

— Adam