> On Mar 26, 2017, at 4:23 AM, [email protected] wrote: > > > > On Mar 25, 2017, at 10:54 PM, John McCall via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >>> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution >>> <[email protected] <mailto:[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.
I wouldn't say it's a fringe case. However, if the program no longer type-checks after migration, that's a pretty clear way of informing the user that something funny is going on and they need to look at it. Suppose instead that the program continues to type-check after migration, but now it uses different declarations. If the declarations would previously have inaccessible, recall that I suggested that the migrator could easily detect that and warn the programmer about the change in behavior. If the declarations were previously accessible, and it's just that somehow a new ambiguity caused the type-checker to prefer a different solution — well, that's starting to feel pretty fringe. If we considered things like that to be completely blocking, we'd be unable to ever change the standard library at all. Remember that the concern here is just that programs will silently change behavior because of migration. Migration is allowed to say that the programs need to be manually fixed; we just don't want that to happen too often, because it's annoying to have to fix a million things when you update. Is anyone actually arguing that this sort of thing is so pervasive in their code that we need to worry about that? John. > >> 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] <mailto:[email protected]>> >>> To: Carl Brown1/US/IBM@IBM >>> Cc: Drew Crawford <[email protected] >>> <mailto:[email protected]>>, Jonathan Hull <[email protected] >>> <mailto:[email protected]>>, swift-evolution <[email protected] >>> <mailto:[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] >>> <mailto:[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] <mailto:[email protected]>> >>> wrote: > Maybe this is the core >>> >>> From: Xiaodi Wu <[email protected] <mailto:[email protected]>> >>> To: Carl Brown1/US/IBM@IBM >>> Cc: Drew Crawford <[email protected] >>> <mailto:[email protected]>>, Jonathan Hull <[email protected] >>> <mailto:[email protected]>>, swift-evolution <[email protected] >>> <mailto:[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] >>> <mailto:[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] <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] <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
