This never went into a review. The pull request is still open https://github.com/apple/swift-evolution/pull/587 > On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution > <[email protected]> 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? > • Or can the Core Team make the change if it is accepted? > > On 11 Apr 2017, at 19:01, John McCall <[email protected] > <mailto:[email protected]>> wrote: > >> >>> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>> >>> On 11 Apr 2017, at 16:27, Matthew Johnson <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> >>>> Sent from my iPad >>>> >>>> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> >>>>>> On 11 Apr 2017, at 13:29, Jonathan Hull <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>>> >>>>>>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution >>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> On 11 Apr 2017, at 09:40, John McCall <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>>>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution >>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution >>>>>>>>> <[email protected] <mailto:[email protected]>> 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 >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
