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