Just as one small data point, I had no idea private extensions still applied fileprivate access to all members (I thought that had changed when SE-0169 was implemented). I’ve been using private extensions extensively because I thought they *did* apply private access to everything, not fileprivate.
Now knowing this isn’t the case, I can only imagine how many other people would be tripped up be this (especially people who haven’t followed Swift Evolution). I definitely think this inconsistency needs to be fixed. > On Oct 4, 2017, at 8:48 PM, BJ Homer via swift-evolution > <[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 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
