> On 5 Oct 2017, at 07:34, Jose Cheyo Jimenez via swift-evolution > <swift-evolution@swift.org> 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.
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. > 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 <tony.allev...@gmail.com > <mailto:tony.allev...@gmail.com>> 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 >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >> >> <https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html> >> >> >> >> >> >> On Oct 4, 2017, at 8:47 PM, BJ Homer <bjho...@gmail.com >> <mailto:bjho...@gmail.com>> 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 >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> >>>> >>>> On Oct 2, 2017, at 9:59 PM, David Hart via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>>> >>>>> >>>>> On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>>> On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>> >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>>>> >>>>>>>> On 01.10.2017 1:18, Chris Lattner wrote: >>>>>>>>>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution >>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>>> >>>> <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 >>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
