<div dir="ltr">On Fri, Mar 24, 2017 at 8:45 PM, Drew Crawford via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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"><span class=""><div id="m_-697912929847412745bloop_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_-697912929847412745bloop_sign_1490403889876158976" class="m_-697912929847412745bloop_sign"></div> <br><p class="m_-697912929847412745airmail_on">On March 24, 2017 at 7:53:09 PM, Jonathan Hull (<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>) wrote:</p> <div><blockquote type="cite" class="m_-697912929847412745clean_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><div style="color:rgb(0,0,0);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">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="color:rgb(0,0,0);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"><br></div><div style="color:rgb(0,0,0);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">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></span><p>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><span class=""><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">Note also that your list above is a list of typical stumbling blocks for new programmers in most languages. Swift has actually done a remarkable job with most of these through careful design of the way that they are framed / exposed to the programmer. In general, these things are well separated from each other. </blockquote></div></span><p>I do not think Swift has done even a *good* job framing these concepts. For example</p><p>protocol Foo {</p><p> func foo() { }</p><p>}</p><p>extension Foo {</p><p> func bar() {}</p><p>}</p><p>One of these is statically dispatched and the other one is dynamically dispatched. I would guess the vast majority of Swift developers are not aware there's a difference at all, let alone can explain why one is slower in a benchmark.</p><p>Swift is good at giving programmers flexibility in their tools. 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. IMO shipping a full toolbox with plenty of overlap is one of the core values of Swift.</p></div></blockquote><div><br></div><div>I could hardly disagree more with this opinion. Figuring out what's statically vs. dynamically dispatched can be very difficult with Swift. Although each rule is defensible when dissected individually, the overall scheme once `final`, `dynamic`, `@objc`, etc. are included is supremely inelegant. Far from being an example of a core value, I would say it's an example of a major weakness. I see one of the key goals of the Swift evolution process as reducing and, where possible, eliminating such designs from the language.</div><div><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"><p>I would suggest that the practicable reason we are talking about removing private/fileprivate instead of protocol/extension or reference/value is that while `extension` etc. makes your code more powerful, `private` makes it less powerful. It is not obvious to everyone why less power is desirable and so here we are.</p><span class=""><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">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></span><p>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>I do use scoped access extensively, and I've left some examples of that upthread.</p><span class=""><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">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></span><p>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><span class=""><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"> In general, Swift is an opinionated language</blockquote></div></span><p>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></div><div></div><div></div><div></div><div></div><div></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>