What scenario are you referring to?
On Sun, Mar 26, 2017 at 03:38 <[email protected]> wrote: > This will not always work, particularly when both symbols already have an > identical type. > > On Mar 26, 2017, at 1:29 AM, Xiaodi Wu <[email protected]> wrote: > > I think this is where some special behavior in the migrator is called for. > Where an overload ambiguity appears, it will need to insert an "as T" to > disambiguate. > > Carl's standard can be strictly met by a migrator that compares all uses > of private facilities under the new and old meaning of private, ensuring > that no uses emerge or disappear after rollback. > On Sun, Mar 26, 2017 at 03:23 Jaden Geller via swift-evolution < > [email protected]> wrote: > > > > On Mar 25, 2017, at 10:54 PM, John McCall via swift-evolution < > [email protected]> wrote: > > On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution < > [email protected]> 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 <[email protected]> > To: Carl Brown1/US/IBM@IBM > Cc: Drew Crawford <[email protected]>, Jonathan Hull <[email protected]>, > swift-evolution <[email protected]> > 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 <*[email protected]* > <[email protected]>> 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 <*[email protected]* > <[email protected]>> wrote: > Maybe this is the core > > From: Xiaodi Wu <*[email protected]* <[email protected]>> > To: Carl Brown1/US/IBM@IBM > Cc: Drew Crawford <*[email protected]* <[email protected]>>, > Jonathan Hull <*[email protected]* <[email protected]>>, swift-evolution < > *[email protected]* <[email protected]>> > 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 <*[email protected]* > <[email protected]>> 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 > [email protected] > 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
