> On Mar 26, 2017, at 4:27 AM, Goffredo Marocchi <[email protected]> wrote: > On 26 Mar 2017, at 06:54, 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. 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.
Scoped-private is not some awesomely expressive feature. It's an access restriction. The "opinion" I'm talking about hardly prevents you from coding however you like. It's just this: organizing your code into smaller, more self-contained components separated by file is good practice anyway, and when you do that, Swift will let you enforce that each component is properly encapsulated. John. > >> >> 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
