<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div><br></div><div><br>On Oct 7, 2017, at 8:28 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>This, I think, is the most persuasive argument available here; it provides a concrete use case to justify why one design is superior to the other.<br></div></blockquote><div><br></div><div>open extension do not exist either. :)</div><br><blockquote type="cite"><div><div class="gmail_quote"><blockquote type="cite" __apple_fixed_attribute="true"><div dir="ltr"><span>On Sat, Oct 7, 2017 at 10:26</span> David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><span></span></div><div>One argument: without this fix, private is the only access level for which we have no means to easily and implicitly apply an access level to a group of members. And it bums me to have to explicitly type private on ever single member to achieve the same result as I can with any other access level.</div></div></blockquote></div></div></blockquote><br></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">In the same way that we need to be explicit about open in extension members or public in public type members; the lowest access version of scope private needs to also be explicit in private extension members and top level private concrete type members. </span></div></div><div><br></div><div>The premise of 169 was never about creating a new version of scope private that could only be used in extensions. It just relaxed the rules for explicit private extension members. </div><div><br></div></body></html>