> On Mar 25, 2017, at 10:54 PM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution >> <swift-evolution@swift.org> wrote: >> Yes, it would change my opinion of it. I wouldn't become a strong supporter >> because I don't see any value in it, but a rigorous proof that this proposal >> could not possibly introduce regressions to any existing codebases would >> change my opinion from "strongly against" to "doesn't matter to me, I'll >> stop arguing against it and go get my real work done". >> > Speaking just for myself, this was a key part of why I was attracted to this > proposal: it seemed to me to be extremely unlikely to cause regressions in > behavior. Even without any special behavior in the migrator, code will > mostly work exactly as before: things that would have been invalid before > will become valid, but not the other way around.
What about overloads that become ambiguous? I admit this is a fringe case. > The exception is that old-private declarations from scopes in the same file > can now be found by lookups in different scopes (but still only within the > same file). It should be quite straightforward for the migrator to detect > when this has happened and report it as something for the programmer to look > at. The proposal causes a small regression in functionality, in that there's > no longer any way to protect scopes from accesses within the file, but (1) > it's okay for Swift to be opinionated about file size and (2) it seems to me > that a workable sub-module proposal should solve that more elegantly while > simultaneously addressing the concerns of the people who dislike > acknowledging the existence of files. > > John. >> -Carl >> >> <graycol.gif>Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your >> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 >> <Carl.Br >> >> From: Xiaodi Wu <xiaodi...@gmail.com> >> To: Carl Brown1/US/IBM@IBM >> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com>, >> swift-evolution <swift-evolution@swift.org> >> Date: 03/25/2017 12:33 AM >> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels >> >> >> >> >> Would it change your opinion on the proposal? >> >> >> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com> wrote: >> I would very much like to see your proof that the resultant code is >> unchanged in an arbitrary codebase. >> >> -Carl >> >> <graycol.gif>Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at >> 11:55 PM, Carl Brown1 <carl.bro...@ibm.com> wrote: > Maybe this is the core >> >> From: Xiaodi Wu <xiaodi...@gmail.com> >> To: Carl Brown1/US/IBM@IBM >> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com>, >> swift-evolution <swift-evolution@swift.org> >> Date: 03/25/2017 12:01 AM >> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels >> >> >> >> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com> wrote: >> My point is that, in rolling back the specific portion of SE-0025, >> case-sensitive find-and-replace will be the trickiest thing in most >> codebases, save those that result in invalid redeclarations. The behavior of >> the resultant code is, unless I'm mistaken, provably unchanged. >> >> >> >> >> >> _______________________________________________ >> 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
