> Am 22.04.2017 um 05:41 schrieb BJ Homer via swift-evolution > <swift-evolution@swift.org>: > > 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. > +1
-Thorsten > -BJ > > On Apr 21, 2017, at 9:30 AM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >> >>> On Apr 20, 2017, at 7:53 PM, John McCall <rjmcc...@apple.com >>> <mailto:rjmcc...@apple.com>> wrote: >>> >>>> On Apr 20, 2017, at 7:31 PM, Douglas Gregor <dgre...@apple.com >>>> <mailto:dgre...@apple.com>> wrote: >>>>> On Apr 20, 2017, at 3:39 PM, John McCall <rjmcc...@apple.com >>>>> <mailto:rjmcc...@apple.com>> wrote: >>>>> >>>>>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor <dgre...@apple.com >>>>>> <mailto:dgre...@apple.com>> wrote: >>>>>> >>>>>> >>>>>>> On Apr 20, 2017, at 11:33 AM, Jordan Rose <jordan_r...@apple.com >>>>>>> <mailto:jordan_r...@apple.com>> wrote: >>>>>>> >>>>>>> >>>>>>>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
