On Fri, Mar 24, 2017 at 11:09 PM, Drew Crawford <d...@sealedabstract.com> wrote:
> > > > On March 24, 2017 at 10:28:43 PM, Xiaodi Wu (xiaodi...@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. >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
