Sent from my iPhone > On 26 Mar 2017, at 06:54, 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. 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.
The opinionated flag sometimes, like being Swifty, is being used to swath away disagreement, but opinions should be reasonable and pragmatic too... opinionated as "you will code this way and you will like it" seems hardly ideal too if abused constantly. Programming is a creative endeavour too. Also, removing a feature that is used and is useful because "maybe" a year or more away there could be a feature that may address the concerns of the people we are stripping away the current feature from seems quite harsh and unfriendly at best... not very logical either. > > 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
