> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> 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?
This is major change. I would hope for a new review if the proposal is being
accepted.
I would also want this new behavior to be explicit thus making it a non
breaking change.
> • 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
