<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>* What is your evaluation of the proposal?<br class=""></blockquote><div><br class=""></div>-1 Strong.&nbsp;</div><div><br class=""></div><div><div>This proposal should go back to the drawing board because it is incoherent.&nbsp;</div></div><div><br class=""></div><div>This proposal claims to try to remove access modifiers but then also is trying to add them for:</div><div><br class=""></div><div></div><blockquote type="cite" class=""><div><span class="Apple-tab-span" style="white-space:pre">        </span>2.Allow&nbsp;access modifier&nbsp;when&nbsp;type-inheritance-clause&nbsp;is present.</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>3 Access modifier&nbsp;on extensions should respect the modifier of the extended type and the protocol to which it should conform.</div></blockquote><div><br class=""></div><div>First it claims to remove them, then it claims to add them (2) and finally enforce them (3).&nbsp;</div><div><br class=""></div><div>Not to mentioned the proposed solution now has rules for enforce addition of modifiers (3).</div><div><br class=""></div><div>There is more adding than removing. I don’t understand the benefit here. &nbsp;</div><div><br class=""></div><div><blockquote type="cite" class=""><span style="color: rgb(119, 119, 119); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: 24px; widows: 1; background-color: rgb(255, 255, 255);" class="">" If you extend a private type, any new type members you add will have a default access level of private".</span></blockquote></div><div><br class=""></div><div>This is not longer accurate with the new definition of private. Top level extensions will have default access of fileprivate.&nbsp;</div><div><br class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></blockquote><div><br class=""></div>no. I was never confused by access level on extensions. I don’t think this fixes anything but on the contrary.&nbsp;</div><div><br class=""></div><div>I don’t understand what the real problem this proposal is trying to address.&nbsp;</div><div><br class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""></blockquote><div><br class=""></div><div>nope. It takes away a really cool feature and adds weird rules.&nbsp;</div><div><br class=""></div><div>I think extensions are special and they should be treated as so.&nbsp;</div><div><br class=""></div><div>If I want to extend a type as private, let me mark the extension as private and treat the extension score as private.&nbsp;</div><div><br class=""></div><div>These rules are also going to force programers to write fileprivate a lot more often .&nbsp;</div><div><br class=""></div><div>private extension MyType {</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>func1(){}</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>func2(){}</div><div>}</div><div><br class=""></div><div><u class="">with this proposal:</u></div><div><br class=""></div><div><div>[MyType’s access level] extension MyType {</div><div><span class="Apple-tab-span" style="white-space: pre;">        </span>fileprivate&nbsp;func1(){}</div><div><span class="Apple-tab-span" style="white-space: pre;">        </span>fileprivate&nbsp;func2(){}</div><div>}</div></div><div><br class=""></div><div>What if my type is internal? Now I have to write internal all the time.&nbsp;</div><div><br class=""></div><div>internal extension MyTyep{}</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></blockquote><div><br class=""></div>n/a<br class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</blockquote><br class=""></div><div>participated in the original thread.&nbsp;</div><div><br class=""></div><div><br class=""></div><br class=""></body></html>