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 > On Oct 4, 2017, at 8:47 PM, BJ Homer <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> wrote: >> >> >> >>> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
