> On 21 Apr 2017, at 01:31, Douglas Gregor via swift-evolution 
> <[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.

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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to