Sent from my iPad
> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution > <[email protected]> wrote: > > >>> On 11 Apr 2017, at 13:29, Jonathan Hull <[email protected]> wrote: >>> >>> >>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution >>> <[email protected]> wrote: >>> >>> On 11 Apr 2017, at 09:40, John McCall <[email protected]> wrote: >>> >>>>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> Sent from my iPhone >>>>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution >>>>> <[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 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] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
