Great, thanks for the clarification. On Tue, Apr 11, 2017 at 14:50 John McCall <rjmcc...@apple.com> wrote:
> On Apr 11, 2017, at 3:37 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > SE-0169 is under active review, and is about expanding the meaning of > scope to include extensions in the same file. The last day of the review > period is today. > > What is this about yet another change? > > > SE-0169 appears to say that extensions in the same file should not have > access to each other's members if they are not in the same file as the type > declaration. Some reviewers have specifically objected to that clause as > counter to the overall design of SE-0169. Most reviewers appear to have > overlooked it. I have not seen any specific support for that clause that > was not tied to overall disapproval of SE-0169. > > The Core Team often changes minor things like this by fiat after review; > swift-evolution is not a legislative process where every last detail needs > formal approval. We'll have to talk about it if we decide to accept > SE-0169. > > John. > > On Tue, Apr 11, 2017 at 14:31 David Hart via swift-evolution < > swift-evolution@swift.org> wrote: > > We’re not talking about the same proposal. I’m talking about SE-0169 > > On 11 Apr 2017, at 19:49, Daniel Duan <dan...@duan.org> wrote: > > 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 < > 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? > • 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 > > _______________________________________________ > 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
