> 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] >> <mailto:[email protected]>> wrote: >> >>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> On Apr 20, 2017, at 11:33 AM, Jordan Rose <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution >>>>> <[email protected] <mailto:[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). 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. 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. :) John.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
