<div dir="ltr">On Tue, Mar 21, 2017 at 9:15 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_3179151620867632415bloop_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_3179151620867632415bloop_sign_1490147885110106112" class="m_3179151620867632415bloop_sign"></div> <br><p class="m_3179151620867632415airmail_on">On March 21, 2017 at 7:45:22 PM, Zach Waldowski via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>) wrote:</p> <div><blockquote type="cite" class="m_3179151620867632415clean_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:Arial;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">Swift should only impose a preference when it's important to the speed, functionality, and safety of the language. I have yet to be convinced that there's a benefit to a scoped access level that fits anywhere in there.</span></div></span></blockquote></div></span><p>SE-0025 addresses these *specific* points.</p><p>speed & safety:</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">> Also, there is a greater danger of using private APIs if they do something similar to public APIs but are somehow more optimized (because they make additional assumptions about the internal state).</blockquote></div></span><p>functionality:</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 forces a one class per file structure, which is very limiting. Putting related APIs and/or related implementations in the same file helps ensure consistency and reduces the time to find a particular API or implementation. This does not mean that the classes in the same file need to share otherwise hidden APIs, but there is no way to express such sharability with the current access levels.</blockquote></div><blockquote type="cite" style="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"><br></blockquote><div><br></div><br><div></div><div></div><div></div></span><div><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">I have spent entire weeks of class trying to extoll the benefits, so breathlessly shared on these mailing lists, of how beautiful it is to have a scoped access level. I have yet to succeed.</blockquote></div></span><p>Perhaps this suggests scoped access modifiers are more comparable to e.g. “owned” in the Memory Management Manifesto or UnsafeRawPointer/SE-0107. Those features are breathtakingly difficult to teach, with design documents in the dozens of pages that are so dense I do not understand them.</p><p>However, they solve hairy problems down in the dungeon somewhere, and most programmers do not actually need to know them to write their code.</p><p>I don’t think scoped is quite to that level, but even if it were: if you like your visibility modifiers you can keep them! There is no law that says you must use all the modifiers,</p></div></div></blockquote><div>No, but you must understand what all of them mean to reason about code. You can read and write a lot of useful Swift without understanding raw pointers. You cannot reason about Swift code very well if you do not understand access modifiers, especially `private`. If you're arguing that new `private` is necessary to solve "hairy problems down in the dungeon somewhere," it should certainly not be the so-called "soft" default that comes with being named `private`. That is the diametrical opposite of how it was pitched in SE-0025, where it's expected to be the overwhelmingly most common choice.</div><div><br></div><div>And again, interoperability with C is a tentpole feature of Swift, so the balance is different. Swift makes no such promises about encapsulation within a module; in fact, IIUC it's a non-goal. So the balance between power and teachability is distinctly different.<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"><div><p>and the availability of a feature does not “impose on all of us the personal code style preferences” of anyone. Removing a feature does, and that’s the present proposal.</p><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>