[swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions
David Hart
david at hartbit.com
Fri Apr 21 00:15:31 CDT 2017
> On 21 Apr 2017, at 01:31, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>
>
>>> On Apr 20, 2017, at 3:39 PM, John McCall <rjmccall at apple.com> wrote:
>>>
>>> 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> wrote:
>>>>
>>>>
>>>>>> On Apr 20, 2017, at 11:33 AM, Jordan Rose <jordan_rose at apple.com> wrote:
>>>>>>
>>>>>>
>>>>>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution <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.
>
> 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.
It's more than unintuitive, it goes against the reasons we fought for having a more useful private. I want to use the pattern where I declare an extension as private to set all functions inside it as private to create a "private zone".
> - Doug
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170421/49db46d4/attachment.html>
More information about the swift-evolution
mailing list