The "Access Control" section of the Swift 3 book says the following: > You can mark an extension with an explicit access-level modifier (for > example, private extension) to set a new default access level for all members > defined within the extension. The behavior of "private extension" in Swift 3 was a deviation from that model, justified because "private" as a default would have meant that nothing in the extension could ever be called. But it was still contrary to the model suggested by the Swift documentation.
Given the highly restrictive behavior of "private" in Swift 3 and the documentation quoted above, it seems unlikely that a developer would intentionally use "private extension" to mean "please make all this stuff visible to the entire file"—it would have worked, but it seems an odd way to write it. If that were the intention, I think "fileprivate extension" would have been more likely. I think the change to the behavior of "private extension" is in line with the model proposed by SE-0169, in line with the documented behavior of access control on extensions, and in line with user expectations. -BJ > On Apr 21, 2017, at 9:30 AM, Douglas Gregor via swift-evolution > <[email protected]> wrote: > > > >>> On Apr 20, 2017, at 7:53 PM, John McCall <[email protected]> wrote: >>> >>>> On Apr 20, 2017, at 7:31 PM, Douglas Gregor <[email protected]> wrote: >>>>> On Apr 20, 2017, at 3:39 PM, John McCall <[email protected]> wrote: >>>>> >>>>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution >>>>> <[email protected]> wrote: >>>>>> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>>>> On Apr 20, 2017, at 11:33 AM, Jordan Rose <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> This makes the private/fileprivate distinction meaningful for >>>>>>>> extensions. I think also bans the use of "private" at global scope for >>>>>>>> non-nominal types or extensions thereof. A clarifying update to the >>>>>>>> proposal is in order, so developers can better understand the >>>>>>>> semantics. >>>>>>> >>>>>>> Wait, hang on, then people have to write 'fileprivate' instead of >>>>>>> 'private' for top-level typealiases (and functions?). >>>>>> >>>>>> That seems like the correct behavior; private is about members with >>>>>> SE-0169. What do you think? >>>>> >>>>> ...that seems suboptimal, given that the goal has been to make it >>>>> possible for people to use `private` more and not less frequently. IMO, >>>>> there's no need for `private typealias` at the global level to be >>>>> prohibited. >>>> >>>> Yeah, I see no reason for this to change the behavior of private >>>> extensions to be more restrictive than before. >>> >>> So you’re okay with: >>> >>> private extension X { >>> func foo() { } >>> } >>> >>> being equivalent to >>> >>> extension X { >>> fileprivate func foo() { } >>> } >>> >>> rather than >>> >>> extension X { >>> private func foo() { } >>> } >>> >>> ? >>> >>> That seems unintuitive at best. >> >> Perhaps, but it's existing unintuitive behavior. Are you suggesting that >> SE-0169 rationalizes changing it because (1) it's likely that a private >> extension is just meant for the use of other extensions of that type in the >> current file and (2) SE-0169 already allows such uses and so justifies the >> stricter rule? That is an interesting theory, but I'm not sure I believe >> (1). > > I’m saying (2), and I suspect (1) is most often the case… but I agree that > we’re likely to end up breaking code here. > >> More importantly, though, SE-0169 didn't actually propose changing this >> behavior, and it's a very substantial shift in behavior, and we haven't >> actually discussed or gathered any community feedback about it, so I'm >> really struggling to see why it wouldn't need to be a separate evolution >> proposal. > > I was interpreting SE-0169 to mean this, but you are correct: SE-0169 doesn’t > spell out a change here. > >> And that would be difficult because, as a wise man once said to me, the core >> team considers the access-control matter closed for Swift 4 and will not be >> reviewing any further proposals in this area. :) > > Never put stock in charlatans or compiler writers. > > - Doug > > > _______________________________________________ > 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
