Sent from my iPad
> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution >> <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> 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. > > (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 > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
