<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_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="bloop_sign_1490147885110106112" class="bloop_sign"></div> <br><p class="airmail_on">On March 21, 2017 at 7:45:22 PM, Zach Waldowski via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) wrote:</p> <div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 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><p>SE-0025 addresses these *specific* points.</p><p>speed & safety:</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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 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><p>functionality:</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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 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><div><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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 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><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, 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></body></html>