I don't want to make any change until Chris has been able to chime in. If he
agrees with us, what should be done?
• Immediate change in the proposal?
• Would it have to go through a new review?
• Or can the Core Team make the change if it is accepted?
> On 11 Apr 2017, at 19:01, John McCall <rjmcc...@apple.com> wrote:
>
>
>> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>
>>
>> On 11 Apr 2017, at 16:27, Matthew Johnson <matt...@anandabits.com> wrote:
>>
>>>
>>>
>>> Sent from my iPad
>>>
>>>> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>>
>>>>>> On 11 Apr 2017, at 13:29, Jonathan Hull <jh...@gbis.com> wrote:
>>>>>>
>>>>>>
>>>>>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>
>>>>>> On 11 Apr 2017, at 09:40, John McCall <rjmcc...@apple.com> wrote:
>>>>>>
>>>>>>>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution
>>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution
>>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>>>
>>>>>>>>> I have not voted in favor or against the proposal. I have been
>>>>>>>>> reading a lot of responses but I agree with Tony.
>>>>>>>>>
>>>>>>>>> When I started reading the proposal everything was more or less fine
>>>>>>>>> half way through the proposal because it was reverting private to
>>>>>>>>> fileprivate between the type and its extensions within the same file.
>>>>>>>>> I said, if you think of the type and its extensions as a unit then it
>>>>>>>>> makes sense. I can explain that.
>>>>>>>>>
>>>>>>>>> Then it started describing a different behavior among the extensions
>>>>>>>>> located in a file separate from the file containing the definition of
>>>>>>>>> the type. That just started a whole debate inside my head and I
>>>>>>>>> understand the passionate responses on both sides.
>>>>>>>>>
>>>>>>>>> But then I imagined myself explaining this to someone new to Swift
>>>>>>>>> and it just doesn't seem right. If it becomes convoluted then that's
>>>>>>>>> a red flag that it does not belong in Swift.
>>>>>>>>
>>>>>>>> I understand what you are saying and I wouldn't be against relaxing
>>>>>>>> that requirement (not talking for Chris here).
>>>>>>>>
>>>>>>>> The model would change from "Types share scopes with their extensions
>>>>>>>> in the same file the type was defined" to "Types and their extensions
>>>>>>>> share the same scope in each file".
>>>>>>>
>>>>>>> Oh, I had missed that somehow. I agree that that is a very strange
>>>>>>> rule. Do you know why it was proposed that way?
>>>>>>
>>>>>> We had to take a stance and Chris seemed to prefer the rule that was
>>>>>> proposed. I didn't press because I'm sure he has reasons for preferring
>>>>>> it that way. But I have a preference for generalizing visibility to all
>>>>>> extensions, even to those in a different file than the type.
>>>>>
>>>>> I think there is a technical limitation if the visibility goes beyond the
>>>>> compilation unit (unless whole module optimization is turned on).
>>>>
>>>> I’m not suggesting visibility beyond the compilation unit. That would
>>>> break the hierarchy of visibility layers: accessibility levels have always
>>>> been contained in one-another and that’s why you can go from private, to
>>>> fileprivate, to internal, to public, to open (but not the other way round)
>>>> without the risk of any compilation error. If all scopes of a type were
>>>> visible to each other (whatever the file), you could not go from private
>>>> to fileprivate.
>>>>
>>>> I’m talking about extensions of the same type in the same file (but in a
>>>> separate file from the type) to be able to share private members:
>>>>
>>>> Type.swift
>>>>
>>>> struct A {
>>>> }
>>>>
>>>> Other.swift
>>>>
>>>> extension A {
>>>> func foo() {
>>>> bar()
>>>> }
>>>> }
>>>>
>>>> extension A {
>>>> private func bar() {
>>>> }
>>>> }
>>>>
>>>
>>> If this is not how your proposal already works I missed that aspect earlier
>>> and find it extremely perplexing (which is probably why I missed it).
>>
>> It's mentioned in the Derailed design section:
>>
>> This proposal does not change the behavior of extensions that are not in the
>> same file as the type - i.e., extensions in a seperate file to the type do
>> not share access between themselves:
>>
>> But I agree this should be changed if there is no major technical reason
>> against it.
>
> I'm not aware of any technical reason why extensions in the same file should
> not have access to each other's members.
>
> John.
>
>>
>>> It leaves scoped access working as in Swift 3 in exactly the case where it
>>> is least useful. We cannot place stored properties in any extensions, let
>>> alone extensions in a file other than the one containing the original
>>> declaration.
>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
