<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 5, 2017, at 4:32 AM, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; 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;"><div class=""><br class="Apple-interchange-newline">On 5 Oct 2017, at 07:34, Jose Cheyo Jimenez via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""></div><div class="">I appreciate the enthusiasm but this is not a bug. This was a deliberate change in swift 3 to make `private extension` usable. If this was a bug then during swift 3 we should have disallowed `private extension` and only allowed `fileprivate extension` but that is not what happened. `private extension` has worked the same since swift 1. I’ve always used `private extension` when I want to add methods to String or other build in types. </div></div></div></blockquote><div style="font-family: Helvetica; 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; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; 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; -webkit-text-stroke-width: 0px;" class="">It’s not a bug, but its unfortunate the behaviour wasn’t changed at the same time as SE-0169, and it now is very inconsistent. I also don’t have to rehash previous discussions, but if a Core Team member (Chris) is okay with going ahead with this, perhaps we should consider it.</div></div></blockquote><div><br class=""></div><div>This could have not been part of 169 because it would've required to lower the visibility of the private extension modifier.</div><div><br class=""></div><div>“<span style="color: rgb(36, 41, 46); font-family: -apple-system, system-ui, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; orphans: 2; widows: 2;" class="">No migration will be necessary as this proposal merely broadens the visibility of</span><span style="color: rgb(36, 41, 46); font-family: -apple-system, system-ui, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; orphans: 2; widows: 2;" class=""> </span><code style="color: rgb(36, 41, 46); orphans: 2; widows: 2; box-sizing: border-box; font-family: SFMono-Regular, Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 13.6px; padding: 0.2em 0px; margin: 0px; background-color: rgba(27, 31, 35, 0.0470588); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">private</code><span style="color: rgb(36, 41, 46); font-family: -apple-system, system-ui, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; orphans: 2; widows: 2;" class="">.</span>”</div><div><br class=""></div><div>There was a corner case mentioned when dealing with functions with the same name and that was understandable. </div><div><br class=""></div><div>private extension is consistent to the way the private scope rules work. The word private is explicit at the top level because extensions can only be declared at top level. Top level private is always fileprivate. The inconsistency is that we have 1 scope ALC and the rest are not. An explicit declaration should always take precedence when declaring something like an access level override.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><br class="" style="font-family: Helvetica; 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; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; 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;"><div class=""><div dir="auto" class=""><div class="">private is different because it is scoped so because of that it is also different when dealing with extensions. Top level private is always the same as fileprivate thanks to its scoped nature. </div><div class=""><br class=""></div><div class="">Making private the scope ACL was a mistake but that ship has sailed and so has this one imo. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class="">On Oct 4, 2017, at 10:05 PM, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" class="">tony.allevato@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Trust me, I'm the last person who wants to rehash access levels in Swift again. But that's not what's happening here, IMO, and fixing bugs is not just "a change for the sake of changing."<div class=""><br class=""></div><div class="">The current behavior of "private extension" is *incorrect*, because it's entirely inconsistent with how access levels on extensions are documented to behave and it's inconsistent with how other access levels apply to extensions.</div><div class=""><br class=""></div><div class="">Can anyone think of a reason—other than "it's too late to change it"—why "private extension" and "fileprivate extension" should behave the same, and why "X extension { decl }" should be identical to "extension { X decl }" for all X *except* "private"?</div><div class=""><br class=""></div><div class="">Yes, it's absolutely unfortunate that this oversight was not addressed when the other access level changes were made. But we shouldn't have to live with bugs in the language because we're afraid of some unknown amount of churn among code that is already written incorrectly. Nor is fixing this bug declaring open season on other, unrelated access level debates. Do you have data that shows that the amount of code broken because it's using "private" when it really should be saying "fileprivate" is high enough that we should just leave the bug there?</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Oct 4, 2017 at 9:51 PM Jose Cheyo Jimenez via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="auto" class=""><div class=""></div><div class="">There was a high bar for breaking changes in swift 4 and is even higher for swift 5. se-110 was approved and implemented on the premises that it was not a big change but it was breaking code so it got reverted. Sure the migrator was making this easier but the result was a usability regression. I think this is a change just for the sake of changing. This will cause unnecessary churn. Let’s leave ACLs alone for the next few versions of swift unless we have a way better system. </div><div class=""><br class=""></div><div class=""><div class="" style="margin: 0px; font-stretch: normal; font-size: 12px; line-height: normal; font-family: Helvetica;"><span class="" style="font-size: 12pt;"><a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html" target="_blank" class="">https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html</a></span></div><div class="" style="margin: 0px; font-stretch: normal; font-size: 12px; line-height: normal; font-family: Helvetica;"><span class="" style="font-size: 12pt;"><br class=""></span></div><div class="" style="margin: 0px; font-stretch: normal; font-size: 12px; line-height: normal; font-family: Helvetica;"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; font-size: 12px; line-height: normal; font-family: Helvetica;"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; font-size: 12px; line-height: normal; font-family: Helvetica;"><span class="" style="font-size: 12pt;"><br class=""></span></div></div></div><div dir="auto" class=""><div class=""><br class="">On Oct 4, 2017, at 8:47 PM, BJ Homer <<a href="mailto:bjhomer@gmail.com" target="_blank" class="">bjhomer@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">It certainly could break *some* code. But it only breaks code written by an author who wrote ‘private extension’ knowing that ‘fileprivate extension’ was also an option, but still intended it to be shared with the whole file. (If that code was from Swift 2, it would have already been migrated to ‘fileprivate extension’ by the 2->3 migrator.)<div class=""><br class=""></div><div class="">So existing code that says ‘private extension’ was written in a Swift 3 or 4 era when ‘fileprivate’ was an option. If the goal was specifically to share it with the whole file, it seems likely that most authors would have used ‘fileprivate extension’ instead of ‘private extension’, as that better communicates the intention. Regardless, though, we could check against the Swift source compatibility test suite to see how widespread that is.</div><div class=""><br class=""></div><div class="">Regardless, I think this change makes Swift a better language, and I’m in favor of it.</div><div class=""><br class=""><div id="m_693547851496808965AppleMailSignature" class="">-BJ</div><div class=""><br class="">On Oct 4, 2017, at 9:10 PM, Jose Cheyo Jimenez via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">On Oct 2, 2017, at 9:59 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><br class="">On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="auto" class=""><br class=""><br class=""><div id="m_693547851496808965m_565568921357597014AppleMailSignature" class="">Sent from my iPad</div><span class=""><div class=""><br class="">On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_693547851496808965m_565568921357597014Apple-interchange-newline"><div class=""><div class="">On 01.10.2017 1:18, Chris Lattner wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Vladimir, I agree with you on that change, but it’s a separate topic from this one.<br class=""><br class="">Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have.<br class=""></blockquote>Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability.<br class=""></blockquote><br class="">So we have to live with *protected* extension inconsistency for very long time just because core team don't want to even discuss _this particular_ inconsistency(when access level in *private extension* must be private, not fileprivate)?<br class=""><br class="">Yes, we decided that access level for extension will mean a default and top most access level for nested methods, OK. But even in this rule, which already differ from access modifiers for types, we have another one special case for 'private extension'.<br class=""><br class="">Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this)</div></div></blockquote><br class=""></div><div class="">I hate to say it but I'm inclined to agree with Vladimir on this. "private extension" has a useful meaning now distinct from "fileprivate extension", and it was an oversight that <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md" target="_blank" class="">SE-0169</a> didn't include a fix here. On this<span class="Apple-converted-space"> </span><i class="">very narrow, very specific<span class="Apple-converted-space"> </span></i>access control issue I think it would still be worth discussing; like Xiaodi said it's not related to James' original thread-starter.</div></div></blockquote><div class=""><br class=""></div></span><div class="">I agree with this in principle but would not want to see it become a slippery slope back into extremely long access control discussions.</div><span class=""><br class=""></span></div></blockquote><div class=""><br class=""></div><div class="">As I've said elsewhere, I too agree with this in principle. I agree with Jordan that the current state of things is justifiable but the alternative would be somewhat superior, agree that in a vacuum this very narrow and specific discussion might be warranted, and agree also that this could be a very slippery slide down a very steep slope.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Same here. It’s the only grudge I have left with the current access control situation. I remember Doug Gregor and John McCall discussing this during the last access control proposal. And I wouldn’t mind having a very narrow discussion about only this.</div><div class=""><br class=""></div><div class="">I organize my types into extensions for each conformance and for each access control. I can currently implicitly apply public or fileprivate to all members of an extension but I have no way of doing the same for private. That’s why I think it should be fixed.</div></div></blockquote><div class=""><br class=""></div><div class="">This will break a bunch of code because `private extension` has<span class="Apple-converted-space"> </span><u class="">always</u><span class="Apple-converted-space"> </span>meant `fileprivate extension`.<span class="Apple-converted-space"> </span><span class="" style="background-color: rgba(255, 255, 255, 0);">Even Swift 3 had this same behavior. </span>Lowering the access level of the extension members will hide a bunch of code that was visible to the file. </div><div class=""><br class=""></div><div class="">169 was not a breaking change but this “fix” would have made it a breaking change. I doubt 169 would had been accepted if it was a breaking change. I don’t think it’s worth it. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="" style="margin: 0px; font-stretch: normal; font-size: 12px; line-height: normal; font-family: Helvetica;"><span class="" style="font-size: 12pt;"><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md" target="_blank" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md</a></span></div><div class="" style="margin: 0px; font-stretch: normal; font-size: 12px; line-height: normal; font-family: Helvetica;"><span class="" style="font-size: 12pt;"><br class=""></span></div><div class="" style="margin: 0px; font-stretch: normal; font-size: 12px; line-height: normal; font-family: Helvetica;"><span class="" style="font-size: 12pt;"><br class=""></span></div></div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="auto" class=""><span class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">(I maintain that the current model does<span class="Apple-converted-space"> </span><i class="">not</i> include a special case; it simply means the 'private' is resolved at the level of the extension rather than the level of its members. But that isn't what people expect and it's not as useful.)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I agree that changing the behavior of<span class="Apple-converted-space"> </span><i class="">all</i> access modifiers on extensions is out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 'pubic' here indicates that your mental model of extensions does not match what Swift is actually doing, and that could get you into trouble.)</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""></div></blockquote></span><span class=""><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></span></div><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class=""></blockquote></div><br class=""></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote></div></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></blockquote></div><br class=""></body></html>