> On Apr 20, 2017, at 7:53 PM, John McCall <[email protected]> wrote:
>
>> On Apr 20, 2017, at 7:31 PM, Douglas Gregor <[email protected]
>> <mailto:[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).
I’m saying (2), and I suspect (1) is most often the case… but I agree that
we’re likely to end up breaking code here.
> 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.
I was interpreting SE-0169 to mean this, but you are correct: SE-0169 doesn’t
spell out a change here.
> 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. :)
Never put stock in charlatans or compiler writers.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
