<div>Chris's actual quote was:</div><div><br></div><div>"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."</div><div><br></div><div>This is diametrically opposite to "shipping a full toolbox with plenty of overlap."</div><div><br></div><div><br><div class="gmail_quote"><div>On Fri, Mar 24, 2017 at 22:21 Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></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" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Mar 24, 2017, at 6:45 PM, Drew Crawford <<a href="mailto:drew@sealedabstract.com" class="gmail_msg" target="_blank">drew@sealedabstract.com</a>> wrote:</div><div class="gmail_msg"><p class="m_-3168404244112374553airmail_on gmail_msg" 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">On March 24, 2017 at 7:53:09 PM, Jonathan Hull (<a href="mailto:jhull@gbis.com" class="gmail_msg" target="_blank">jhull@gbis.com</a>) wrote:</p><div 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" class="gmail_msg"><blockquote type="cite" class="m_-3168404244112374553clean_bq gmail_msg" 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 class="gmail_msg"><div class="gmail_msg"><div style="font-family:'helvetica Neue',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" class="gmail_msg">It isn’t the fact that there are multiple models, but they way those models interact with each other in the brain. You can actually have lots of different models without causing confusion, as long as the models fit well together. It also isn’t the number of access levels that is a problem. For example, you can have a ton of shirt sizes (XS, S, M, L, XL, XXL, 3XL) and it doesn’t cause more confusion as you add more sizes because they don’t conflict with one another.</div><div style="font-family:'helvetica Neue',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" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:'helvetica Neue',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" class="gmail_msg">A big part of the issue with our current access scheme is how similar the concepts are without being the same. That is then made worse by the fact that they have been given similar names.</div></div></span></blockquote></div><p 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" class="gmail_msg">It is unclear what distinction you intend to draw here. For example, value types and reference types are similar without being the same. The names of both concepts also contain the substring "type". So the difference you draw between that situation and the private/fileprivate situation is not immediately clear.</p></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">The distinction between value and reference types is one of the most confusing aspects of learning to program. We are helped a bit by the fact that we use the concrete Class, Struct, and Enum. Many programmers just think of Classes as behaving differently than Structs/Enums and don’t really think about it as value vs reference. We never write valueType or referenceType in swift (only when having abstract discussions here on Evolution). Notice also that swift doesn’t use the term “pass-by-reference”. It has explicitly avoided using those terms in actual swift code.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I agree with you about statically vs dynamically dispatched being an issue. For the most part, Swift tries to make it so we don’t ever have to think about it, but when the distinction does poke through, it can be confusing. I think we will need to do some redesign work here when more dynamic features are added. I had a proposal a while back to allow power users to force static dispatch by disambiguating the implementation which gets used. I will probably re-propose that when it seems in scope.</div><div class="gmail_msg"><br class="gmail_msg"></div>It may help if I clarify that a mental model is not how something actually works, but rather our model of how we *think* it works. Mental models are almost always incorrect, but they are good enough to get by... for the most part. (<a href="https://www.nngroup.com/articles/mental-models/" class="gmail_msg" target="_blank">https://www.nngroup.com/articles/mental-models/</a>)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In your examples above, Swift is projecting a system image which is much simpler than the underlying concepts (e.g. your statement about static vs dynamic typing that: "I would guess the vast majority of Swift developers are not aware there's a difference at all”). This helps to avoid confusion (except where rough spots poke through the facade).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">For access controls, the user is being presented with the full complexity of that choice directly.</div><div class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><p 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" class="gmail_msg">Here we have two superficially similar tools with slightly different features and performance characteristics, and for most problems it does not even matter which one you choose. </p></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">This is exactly the problem. Both for access controls and dispatch.</div><div class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><p 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" class="gmail_msg">IMO shipping a full toolbox with plenty of overlap is one of the core values of Swift.</p></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">Is it? Can you point to an instance where a member of the core team said they are aiming for “plenty of overlap”?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div 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" class="gmail_msg"><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" class="gmail_msg">Do you feel that allowing both scoped private & file-based private is actually important enough to warrant the significant design work it would take to bring it up to par with these other features? </blockquote></div><p 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" class="gmail_msg">It is not clear to me what design work is actually outstanding. I would love to see submodules, but that seems only indirectly related to visibility keywords, and I'm not aware of what you seem to believe we need.</p><p 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" class="gmail_msg">I do use scoped access extensively, and I've left some examples of that upthread.</p></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Honestly, most of your examples could just be split into multiple files. They might also benefit from submodules.</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div 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" class="gmail_msg"><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" class="gmail_msg">It is not impossible, but it really doesn’t feel worth the effort to me (say compared to using that time/energy/thought to check off features from the generics manifesto).</blockquote></div><p 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" class="gmail_msg">Rather, as Carl Brown argued, it would take a lot of time/energy to migrate even the official projects off of private/fileprivate. Keeping what we have is free, change is what is expensive, and this proposal is change.</p></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">You are conflating effort by the swift design and implementation community with your personal effort around migration.</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"> </div><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div 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" class="gmail_msg"><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" class="gmail_msg"> In general, Swift is an opinionated language</blockquote></div><p 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" class="gmail_msg">Not clear what you mean here either. Swift is clearly less opinionated than ObjC for example. I am having trouble connecting this claim to a practical application.</p></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">Oh, that is a quote from Lattner, when he was describing the core philosophy behind Swift. Others can probably dig up the actual quote. It has been repeated over and over.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><br class="gmail_msg"></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div>