<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035885.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035885.html</a><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 9, 2017 at 17:05 David Hart <<a href="mailto:david@hartbit.com">david@hartbit.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Do you a have a link to that discussion?</div><div dir="auto"><br><div><br>On 10 Aug 2017, at 00:04, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>Agree, but again, I tried, and the answer was no, it’s not considered a bug and cannot be fixed without independent discussion.<br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 9, 2017 at 16:51 David Hart <<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">The last thing I want is to launch into a new round of discussions. I am just hoping it can be considered as a straight bug that can be fixed without any discussion.</div><div dir="auto"><br><div><br>On 9 Aug 2017, at 23:47, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>I brought this up after SE-0169, but it was deemed to be a separate issue and any further consideration was declined. Let’s not initiate another round of access control discussions.<br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<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">Actually, I think this is this way only as a relic from the original <font face="Menlo">private/fileprivate</font> proposal. Swift 3’s <font face="Menlo">private</font> has no meaning as an extension modifier, so it was made to alias to <font face="Menlo">fileprivate</font>. But since SE-0169 modified <font face="Menlo">private</font>’s meaning so that it would make sense as an extension modifier, I think we should fix this.</div><div style="word-wrap:break-word"><div><br><div><blockquote type="cite"><div>On 9 Aug 2017, at 23:22, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-4830049329256588518m_698931507616099936m_7997858394294865225Apple-interchange-newline"><div><div style="word-wrap:break-word">That behaviour was never explicitly mentioned in SE-0169 but I agree its confusing. But I’m also fairly sure the only window to do anything about it is Swift 4. Everybody is really worn down by those access level discussions.<div><br></div><div>For illustration, Vladimir is confused that:</div><div><br></div><div><font face="Menlo">private extension Foo {</font></div><div><font face="Menlo"> func foo() {}</font></div><div><font face="Menlo">}</font></div><div><br></div><div>is equivalent to:</div><div><br></div><div><div><font face="Menlo">fileprivate extension Foo {</font></div><div><font face="Menlo"> func foo() {}</font></div><div><font face="Menlo">}</font></div><div><br></div><div>making it accessible to another type in the same file:</div><div><br></div><div><font face="Menlo">struct Bar {<br> func bar(foo: Foo) {<br> foo.foo()<br> }<br>}</font></div><div><br></div><div>Aren't access levels on extensions supposed to define the default access level of the members of the extension?Is this a bug then?</div><div><br><div><blockquote type="cite"><div>On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-4830049329256588518m_698931507616099936m_7997858394294865225Apple-interchange-newline"><div><div>Could someone remind please, was it decided to stick with 'private extension' means actually fileprivate access level for members declared in such extension or this could be discussed for Swift5?<br><br>Currently, when private members are visible in type/extensions of that type in the same file, IMO there is no sense to treat 'private extension' as 'fileprivate extension', it is reasonable to group some private members of type into extension without making them fileprivate, and such members can be used from the type/other extensions.<br><br>And also this is a huge inconsistency in my opinion: all other access modifiers 'work' as expected for extensions, but only 'private extension' means not what written, very surprising for one who don't expect this.<br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></div></blockquote></div><br></div></div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></blockquote></div></blockquote></div>
</div></blockquote></div></blockquote></div>