<div dir="ltr">On Fri, Mar 24, 2017 at 11:09 PM, Drew Crawford <span dir="ltr">&lt;<a href="mailto:drew@sealedabstract.com" target="_blank">drew@sealedabstract.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div id="m_3405518648656214337bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> <br> <div id="m_3405518648656214337bloop_sign_1490413300878596096" class="m_3405518648656214337bloop_sign"></div> <br><p class="m_3405518648656214337airmail_on">On March 24, 2017 at 10:28:43 PM, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>) wrote:</p> <div><blockquote type="cite" class="m_3405518648656214337clean_bq" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span><div><span style="color:rgb(0,0,0);font-family:&#39;helvetica Neue&#39;,helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline!important">I&#39;m not sure where you&#39;re reading that Chris thinks the current design reaches the stated aims to his satisfaction.</span></div></span></blockquote></div><p>I&#39;m pretty sure it&#39;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.</p><div><blockquote type="cite" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-top-width:1px;border-right-width:1px;border-bottom-width:1px;padding-left:5px;border-left-width:1px!important;border-left-color:rgb(0,64,128)!important">&quot;We intentionally want Swift to have a common &#39;center of gravity&#39; and be an &#39;opinionated&#39; language, rather than fall to the &#39;design by committee&#39; approach that leads to a watered-down design.&quot;  This is diametrically opposite to &quot;shipping a full toolbox with plenty of overlap.&quot;</blockquote></div><p>Chris has elaborated on this <a href="http://atp.fm/205-chris-lattner-interview-transcript/" target="_blank">elsewhere</a>:</p><div><blockquote type="cite" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-top-width:1px;border-right-width:1px;border-bottom-width:1px;padding-left:5px;border-left-width:1px!important;border-left-color:rgb(0,64,128)!important"><p>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&#39;s just its subtle way of encouraging you to use immutable values, which is a very small thing, but it&#39;s just pushing you in the way that it thinks leads to a better code. Immutability for a local variable doesn&#39;t matter that much except that it communicates something more to the person who has to read and maintain your code.</p><p>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&#39;re saying, &quot;Should something be a class or a struct?”, the trade-offs are more nuanced and it&#39;s a harder thing, and the Swift compiler can&#39;t just know what problem it is that you want to solve, so it can&#39;t help you with that.</p></blockquote></div><p>`let` and `var` are &quot;redundant&quot; 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 &quot;Swift is an opinionated language&quot; and an argument to the principle of least power.  The analogous idea would be if the compiler offered a fixit to change &quot;fileprivate&quot; to &quot;private&quot; where legal.</p></div></blockquote><div>This was already brought up on the list. There was some consensus that it&#39;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`.</div><div><br></div><div>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&#39;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&#39;ve got a pretty good sign that having both `fileprivate` and `private` is a pervasive problem for users.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><p>Actually, that would be an interesting proposal, especially since some believe private/fileprivate is hard to learn.</p><p>But &quot;Swift is an opinionated language&quot; is not a battlecry for eliminating &quot;redundant&quot; keywords, it is an exhortation to use them correctly.</p><div></div><div></div><div></div></div></blockquote></div><br></div></div>