> On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution >> <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> 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. >> > > 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. >>> >>> (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 >> > > _______________________________________________ > 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
