[swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions
rjmccall at apple.com
Thu Apr 20 17:39:59 CDT 2017
> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
>> On Apr 20, 2017, at 11:33 AM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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.
>> Apart from whether or not that's desirable, it's not backwards-compatible.
> Very true! It’s an easy thing to migrate, but it’s a source break nonetheless. Let’s decide if it’s desirable and bring it up with the core team.
> - Doug
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution