> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution > <[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] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
