> On Oct 2, 2017, at 9:59 PM, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> 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.
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 >>>> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
