> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution > <[email protected]> wrote: > > 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
I understand your point. Another aspect of SE-0169 is that fileprivate should be more rare and thus meaningful when used. The current behavior stays true to the goal of making fileprivate rare. A top level private scope is effectively fileprivate so it is not totally weird for the extension members to inherit the top level private scope. When extensions gain the ability to contain properties, we should not allow the access level modifiers to the extensions in the same way protocol extensions prohibit its use. > >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
