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

[Nevin Brackett-Rozinsky]

As I see it, this new proposal misses the mark in both directions. It does
not replace file-level visibility, because extensions of external types
wouldn’t be able to work with private declarations in the same file. And it
throws out a major use-case of scope-based access, which is to ensure that
invariants are only touched in specific places.

The vast majority of the time, if I am working in a file I want to be able
to access everything in that file. I think this is a phenomenal mental
model to have. It is extremely simple, it covers the most common use cases
perfectly, and it should be the soft default.

To the extent that we want to support protecting things within a file, it
is most beneficial to mark those declarations with a lengthy, unmistakeable
blazon. That way when you are reading code and come across something like
“fragilelocallyscoped var doNotBreakThisInvariant” you know that you must
be extra cautious about modifying it. In particular, such
invariant-sensitive items should not use the same keyword as other members,
because if they did there would be no warning sign for them.

Let me be abundantly clear: when someone is working in a file, they can
always change the access level of members if necessary. In order to protect
invariants, scoped visibility must very clearly inform readers that *this
item should not be touched* except via dedicated channels, and that its
visibility *should not be changed* as well. To convey that, those
declarations need to be distinct and unmistakable.

If you are reading through a file with many “private” declarations and one
or two “dangerproceedwithcaution” declarations, you are much more likely to
think twice before widening an access level in a potentially
invariant-breaking way than if they were all just “private”.

So, if we are going to keep scope-based visibility at all, it should
*definitely not* be spelled “private”. A longer, more-explicit keyword that
stands out prominently would be best, though nearly anything including
“scoped” would suffice as long as it is different from “private”.

We *must not* spell the invariant-protecting, danger-warning access level
“private”.

Leaving it as it is now would be *actively harmful*. Swift 4 is our last
realistic chance to get this right. We made a mistake in Swift 3. For our
own sake, and for the sake of the Swift language and its evolution process,
please let us fix this.

We can simultaneously solve the problem, retain scoped visibility, and
restore the file-level meaning of “private”, simply by changing the
spelling of two keywords. The core team’s reason for disfavoring that
approach, namely “churn”, is easily overcome, as they themselves noted, by
a fully automated migrator.

Nevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170404/a7973fca/attachment.html>