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

First, Chris neither initiated the static/dynamic distinction in that
discussion, nor was the discussion about Swift design goals in general.
Rather, he was explaining the design goals specifically behind the current
hybrid model for dispatch in a thread about dispatch (the thread was titled
"universal dynamic dispatch for method calls"), and I see no claim about
how well the design as implemented in Swift lines up with the goals.

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

There is more than one way in which Swift can be opinionated. In the
excerpt I provided, Chris was speaking about the evolution process. The
very next sentence after "..watered-down design" is: "This means that
decisions are really all shades of gray and cannot be specified or
predicted by algorithm." In some cases, the shades of gray come down in
favor of keeping two things; in others, it does not. Arguments must be
weighed in the context of specific design goals. Chris specifically says
that there is no generalizable algorithm, and one cannot point to `let` and
`var` and say that access levels should be this way or that.

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.  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/3a856c9c/attachment.html>