[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu]

On Fri, Mar 24, 2017 at 11:09 PM, Drew Crawford <drew at sealedabstract.com>
wrote:

>
>
>
> On March 24, 2017 at 10:28:43 PM, Xiaodi Wu (xiaodi.wu at gmail.com) wrote:
>
> I'm not sure where you're reading that Chris thinks the current design
> reaches the stated aims to his satisfaction.
>
> I'm pretty sure it's a fair assumption that when he introduces the
> static/dynamic system to illustrate the design goals of Swift, he means
> those goals can be seen in that feature to some significant extent.
>
> "We intentionally want Swift to have a common 'center of gravity' and be
> an 'opinionated' language, rather than fall to the 'design by committee'
> approach that leads to a watered-down design."  This is diametrically
> opposite to "shipping a full toolbox with plenty of overlap."
>
> Chris has elaborated on this elsewhere
> <http://atp.fm/205-chris-lattner-interview-transcript/>:
>
> Another thing to keep in mind is that Swift is opinionated, I guess is the
> way to say it. It really does encourage you to do the right thing where it
> can. For example, if you use var for everything, the Swift compiler
> [1:21:30] will say, hey, you marked this as a var but it could be a let,
> and let me fix it for you. That's just its subtle way of encouraging you to
> use immutable values, which is a very small thing, but it's just pushing
> you in the way that it thinks leads to a better code. Immutability for a
> local variable doesn't matter that much except that it communicates
> something more to the person who has to read and maintain your code.
>
> I think that Swift really does [1:22:00] encourage you down the right
> lines in some ways. But on the other hand, in other places where you're
> saying, "Should something be a class or a struct?”, the trade-offs are more
> nuanced and it's a harder thing, and the Swift compiler can't just know
> what problem it is that you want to solve, so it can't help you with that.
>
> `let` and `var` are "redundant" in the same way as private/fileprivate;
> one can effectively replace the other.  Far from advocating we should
> eliminate the redundant keyword, he argues the compiler should encourage
> it, because "Swift is an opinionated language" and an argument to the
> principle of least power.  The analogous idea would be if the compiler
> offered a fixit to change "fileprivate" to "private" where legal.
>
This was already brought up on the list. There was some consensus that it's
inconsistent with the changes in SE-0025 because that proposal specifically
allows higher access levels to be used even when the effective visibility
is more limited. A fix-it such as you suggest would make a one-off
exception to that rule for `fileprivate`.

Moreover, it was thought that the predominant scenario in which
`fileprivate` is used where `private` is sufficient was due to Swift 2-to-3
migrator artifact. If so, it's overkill to carve out a _permanent_
exception that complicates the rules for using access modifiers instead of
improving the migrator. On the other hand, if the predominant scenario in
which this fix-it would be triggered is _user_ error, then we've got a
pretty good sign that having both `fileprivate` and `private` is a
pervasive problem for users.

> Actually, that would be an interesting proposal, especially since some
> believe private/fileprivate is hard to learn.
>
> But "Swift is an opinionated language" is not a battlecry for eliminating
> "redundant" keywords, it is an exhortation to use them correctly.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/0dc5d3f1/attachment.html>