• What is your evaluation of the proposal? -1 as written (see below) • Is the problem being addressed significant enough to warrant a change to Swift? Not as written
• Does this proposal fit well with the feel and direction of Swift? It does in terms of apparent simplicity, but not in terms of practicality. I like to think of Swift as a practical language that does not sacrifice utility for apparent simplicity. • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? Can’t be compared. Swift has already set a precedent by making “private” mean something non-traditional (pre SE-0025), and I think it was a good decision, taking us away from the idea that private is only useful with parent inheritance structures. • How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Have been following it since SE-0025, the aftermath, extensive experience using the modifiers in framework code I write and reading all related threads on SE. *** I propose instead that we revise to use Alternative #3, per Vladimir’s comment and revision. Revised version: “3. Revert private to be file-based and introduce the scope-based access level under a new name (e.g.: scoped, local, etc), provided that the scope-based access modifier is not used at the top level of the file.” (addendum via Vladimir’s revised comment) David > On Mar 26, 2017, at 2:30 PM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > > > Sent from my iPad > > On Mar 26, 2017, at 4:13 AM, John McCall via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >>> On Mar 26, 2017, at 4:27 AM, Goffredo Marocchi <[email protected] >>> <mailto:[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. > > This does not address the case where we have a small helper type that is only > 10s of lines long, is not visible outside the file, and encapsulates an > important part of the implementation using scoped private. The whole file is > usually only a couple hundred lines. This is not an excessively long file > and already contains a single component that is presented to the rest of the > program. > > Some designs of submodules might allow us to properly encapsulate everything > but if that requires us to put a small helper type in a separate file that > would be a very unfortunate and inflexible constraint on how we are able to > organize our code. > > I don't want encapsulation concerns dictating how I physically organize my > code. That is significant and unnecessary complexity if you ask me. It > forces a tradeoff between desired physical organization and desired > encapsulation. We should not force users to make this tradeoff. > >> >> 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] <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> David James
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
