> 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.
> 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
