Yes, you're right about the history of "private extension"—I was forgetting some of the details of what transpired during those proposals. Thanks for the reminder.
That being said, I would still argue that it would be a shame if we decided that the language should propagate a known inconsistency indefinitely simply because it was overlooked during a proposal that could have fixed it. I'd weigh the reduction of future user confusion as more valuable than the cost for existing code to do a one-time migration, but that might be easy for me to say because I don't use access levels on extensions at all in my own code so I don't have any skin in the game. :) On Wed, Oct 4, 2017 at 10:33 PM Jose Cheyo Jimenez <[email protected]> wrote: > 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. > > 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. > > Making private the scope ACL was a mistake but that ship has sailed and so > has this one imo. > > > > On Oct 4, 2017, at 10:05 PM, Tony Allevato <[email protected]> > wrote: > > 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." > > 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. > > 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"? > > 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? > > On Wed, Oct 4, 2017 at 9:51 PM Jose Cheyo Jimenez via swift-evolution < > [email protected]> wrote: > >> 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. >> >> >> https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html >> >> >> >> >> >> >> On Oct 4, 2017, at 8:47 PM, BJ Homer <[email protected]> wrote: >> >> 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.) >> >> 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. >> >> Regardless, I think this change makes Swift a better language, and I’m in >> favor of it. >> >> -BJ >> >> On Oct 4, 2017, at 9:10 PM, Jose Cheyo Jimenez via swift-evolution < >> [email protected]> wrote: >> >> >> >> On Oct 2, 2017, at 9:59 PM, David Hart via swift-evolution < >> [email protected]> wrote: >> >> >> >> On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution < >> [email protected]> wrote: >> >> On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution < >> [email protected]> wrote: >> >>> >>> >>> Sent from my iPad >>> >>> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution < >>> [email protected]> wrote: >>> >>> >>> >>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution < >>> [email protected]> wrote: >>> >>> On 01.10.2017 1:18, Chris Lattner wrote: >>> >>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution < >>> [email protected]> wrote: >>> >>> Vladimir, I agree with you on that change, but it’s a separate topic >>> from this one. >>> >>> 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. >>> >>> 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. >>> >>> >>> 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)? >>> >>> 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'. >>> >>> 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) >>> >>> >>> 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 SE-0169 >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md> >>> didn't >>> include a fix here. On this *very narrow, very specific *access control >>> issue I think it would still be worth discussing; like Xiaodi said it's not >>> related to James' original thread-starter. >>> >>> >>> I agree with this in principle but would not want to see it become a >>> slippery slope back into extremely long access control discussions. >>> >>> >> 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. >> >> >> 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. >> >> 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. >> >> >> This will break a bunch of code because `private extension` has *always* >> meant `fileprivate extension`. Even Swift 3 had this same behavior. Lowering >> the access level of the extension members will hide a bunch of code that >> was visible to the file. >> >> 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. >> >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md >> >> >> >> >> >> >>> (I maintain that the current model does *not* 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.) >>> >>> >>> I agree that changing the behavior of *all* 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.) >>> >>> Jordan >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
