> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution > <swift-evolution@swift.org> wrote: > > I think I we can live with the original three: public, internal, and private > > Where public is visible to all, > Internal is visible to all within the module, and private is visible only to > the class and the same file. > > We can still fulfill the same roles that the current five fill. > > Open can become public again. > Public can become final public > Internal remains the same > Fileprivate assimilates into private > > Make access control simple again!
Agree. To me this discussion exemplifies the “square peg in a round hole” problem. None of these (fileprivate & open) keywords add information to a source code. They do add noise however. The difference between fileprivate and private is only of importance to a group development effort. And then it is used for internal communication within that group, never to the outside world. In a way “private” tells other group members that they should ask the original developer why he choose private instead of fileprivate. (And more than often be told “just change it”) This is something that would be better solved by comments imo. Open vs public is less obvious as there seems to be a use case for this. However in the end it only “forces” an API user to wrap the “public” interface so he can then use it again as “open”. Hence it does not solve a design problem, it only leads to a cumbersome interface. Now, if we really want to add information to the source code, then we would do away with the restriction approach entirely and adopt an access list approach. I.e. it would be possible to specify for each interface element which other module/file has access to it. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > > On Sun, Feb 12, 2017 at 9:42 PM Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > On Sun, Feb 12, 2017 at 8:37 PM, Dietmar Planitzer <dplanit...@q.com> wrote: > I know that private was scoped to files before Swift 3. > > Fileprivate should obviously be removed because it is, like I said > previously, just a poor man’s package access level. Yes, private was scoped > to a file before Swift 3, but at least there wasn’t two kinds of private for > a single file. Also scoping private to a file makes sense in Swift because it > plays well with the ability to organize the implementation of a type inside > of a file into the base type and a number of extensions. I now have to use > fileprivate in Swift 3 to pull this off while there isn’t a requirement for a > separate private access level. The fileprivate / private distinction also > needlessly gets in the way when you want to refactor an existing type > implementation into base type + extensions, all living in the same file. > > Anyway, I don’t see a good reason why we should end up with this, once > sub-modules exist: > > open, public, module, fileprivate, private > > when we can live with this: > > open, public, module, private > > and we’re not losing anything that would be significant compared to the > alternative scenario. > > Well, there's also internal: open, public, internal, (submodule, however it > is named), private. > > The question being discussed here is whether private should have the old or > new meaning. I tend to agree with others that the new `private` doesn't add > much. Modules are a different conversation. > > Regards, > > Dietmar Planitzer > > > On Feb 12, 2017, at 18:16, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > > > What was added in Swift 3 was `private`; the old `private` was renamed > > `fileprivate` with no change in behavior. Certainly, submodules are a big > > topic that deserves careful consideration. But the question being discussed > > here is about rolling back the change that was implemented in Swift 3 by > > removing `private` and restoring `fileprivate` to its old name. > > > > > > On Sun, Feb 12, 2017 at 8:08 PM, Dietmar Planitzer via swift-evolution > > <swift-evolution@swift.org> wrote: > > Fileprivate is a feature that should not have been added to Swift 3 because > > it is in the end just a needlessly limited version of the Java package > > access level. Fileprivate forces me to put all types which are related on > > an implementation level into the same file while Java packages allow me to > > put each type implementation into a separate file. The only thing that Java > > requires is that all files which are part of the same package are tagged > > with the same package id. Java’s package access level is more powerful than > > fileprivate because it gives me more freedom in how I want to organize my > > code while still making sure that code in sibling and parent packages can > > not access symbols inside my package which form part of the implementation > > details of my package. > > > > The first thing that needs to happen before any more access levels are > > added is that a concept of sub-modules is added to Swift along the lines of: > > > > 1) modules can be organized into a tree with one module as the root. > > > > 2) all modules which are nodes in the same module tree form a single > > resilience domain. > > > > IMO, the sub-module stuff should be designed similar if not the same way as > > Java packages because there are already lots and lots of SDEs who know how > > Java packages work, and Java packages are well understood, simple and > > straight-forward in their mechanics. > > > > Once sub-modules are in place, it makes sense to revisit the access level > > topic. Eg in order to add a “module” access level that represents the scope > > of a module. So “module” could then do what file private can do today plus > > more. But we should stop trying to add more access level to the language > > until then. We also need to look much more at the bigger picture of things > > instead of getting too much hung up on a single component of a larger > > mechanism, when it is that larger mechanism that is primarily interesting > > and relevant. > > > > > > > > Regards, > > > > Dietmar Planitzer > > > > > On Feb 12, 2017, at 16:16, Zach Waldowski via swift-evolution > > > <swift-evolution@swift.org> wrote: > > > > > > I vehemently agree on these points. New-private and fileprivate "[add] > > > more information" to a file the same way requiring `self.` and other > > > sorts of visual noise that Swift normally eschews. > > > > > > I wish for the Swift community to be introspective enough to count both > > > its successes and failures. SE-0025 was a botched addition to the > > > language. That the migrator did such a bad job is evidence of its poor > > > overall consideration. Adding a fix-it strikes me as the compiler > > > waggling its finger at me for code that would've been perfectly fine in > > > the past, something that it is not at all true with the "let" fix it; > > > accidental mutation has been discussed a ton by the larger programming > > > community, not-so-much for obscure access control mechanics. > > > > > > It's perplexing that fileprivate advocates continue to stand on mostly > > > theoretical benefits about new-private. I feel nothing for the > > > mathematical purity about the types in a file. In practice, I can with > > > much experience now how awful it is. There has been no end to the > > > confusion its introduction has inflicted upon my team(s), people new to > > > the language, and people revisiting the language: > > > > > > - My teams and coworkers are less effective at code review from constant > > > litigation about access control. "'Did this need to change?' / 'No, it > > > was just the migrator.'" has become a disturbingly common refrain. > > > > > > - New users are just struggling to figure out where to put the curly > > > braces in the first place. Having to make them check and re-check where > > > things go in a file, or just tell them to use this clunky > > > get-out-of-jail-free keyword, feels like visiting a special kind of > > > Pythonic hell on a language I otherwise love and love to teach. > > > > > > - People returning to the language feel (and often say - just look at > > > Twitter) Swift has a lot of syntax, and are frustrated that the addition > > > of a new keyword was burned on adding something that amounts to mostly a > > > stylistic opinion. > > > > > > All the best, > > > Zachary Waldowski > > > z...@waldowski.me > > > > > > On Sun, Feb 12, 2017, at 04:45 PM, Xiaodi Wu via swift-evolution wrote: > > >> On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson > > >> <matt...@anandabits.com> wrote: > > >> > > >> > > >>> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution > > >>> <swift-evolution@swift.org> wrote: > > >>> > > >>> _Potentially_ meaningful, certainly. But what I'm hearing is that it > > >>> isn't actually meaningful. Here's why: > > >>> > > >>> If I see `fileprivate` and can understand that to mean "gee, the author > > >>> _designed_ this member to be visible elsewhere inside the file," then > > >>> it's actually meaningful. OTOH, if I see `fileprivate` and can only > > >>> deduce "gee, the author mashed some button in his or her IDE," then > > >>> it's not really telling me anything. > > >> > > >> > > >> You’re looking at it backward. It’s when you see `private` and can > > >> deduce “this member is only visible inside it’s declaring scope” that > > >> can be really helpful. *This* is what matters. > > >> > > >> In what ways can that information help you? > > >> > > >> > > >>> What you've said above, as I understand it, is that it's not currently > > >>> meaningful to see `fileprivate` because the migrator is writing it and > > >>> not the author. The improved approach you proposed is the additional > > >>> warning. In that case, the compiler will help to ensure that when I see > > >>> `fileprivate`, at least I know it's necessary. But that's only telling > > >>> me a fact (this member is accessed at least once outside the private > > >>> scope), but it's still machine-based bookkeeping, not authorial intent. > > >> > > >> > > >> The important thing is that this machine-based bookkeeping results in a > > >> proof about the code. This facilitates reasoning about the code. You > > >> can make an argument that this proof is not important enough to matter, > > >> but you must admit that this is a real concrete gain in information that > > >> is immediately available to a reader of the code (after they know that > > >> it compiles). Personally, I find this proof to be valuable. > > >> > > >> Comparison has been made to `let` and `var`. In that case, whether a > > >> variable is mutated can be non-trivial to deduce (as Swift has no > > >> uniform scheme for distinguishing mutating from non-mutating functions; > > >> the ed/ing rule has many exceptions). By contrast, here, I don't see any > > >> gain in information. You can literally *see* where the (file)private > > >> member is accessed, and when a file gets too long, even a simple text > > >> editor can do a decent enough find. > > >> > > >> If you're right that the real value is that seeing `private` helps you > > >> reason about the code, then that value must be commensurate to how often > > >> we see Swift users amending the migrator to take advantage of it. For > > >> me, the compelling evidence that Swift users don't find this proof to be > > >> valuable is that, by examination of Swift 3 code, Swift users haven't > > >> bothered. If we add a new fix-it to force them to, then of course > > >> they'll mash the buttons, but it's pretty much declaring that they are > > >> wrong not to care about what it seems they do not care at present. > > >> > > >>> On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <sa...@nondot.org> wrote: > > >>> I don't fully agree: you are right that that is the case when writing > > >>> code. However, when reading/maintaining code, the distinction is > > >>> meaningful and potentially important. > > >>> > > >>> -Chris > > >>> > > >>> > > >>> On Feb 12, 2017, at 12:02 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > >>>> If the overwhelming use case is that developers should pick one over > > >>>> the other primarily because it looks nicer, then blindly click the > > >>>> fix-it when things stop working, then the distinction between private > > >>>> and fileprivate is pretty clearly a mere nuisance that doesn't carry > > >>>> its own weight. > > >>>> On Sun, Feb 12, 2017 at 13:33 Jean-Daniel via swift-evolution > > >>>> <swift-evolution@swift.org> wrote: > > >>>>> Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution > > >>>>> <swift-evolution@swift.org> a écrit : > > >>>>> > > >>>>> On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution > > >>>>> <swift-evolution@swift.org> wrote: > > >>>>>> Final > > >>>>>> Can someone tell me what is the use of 'final' now that we have > > >>>>>> 'public' default to disallowing subclassing in importing modules? I > > >>>>>> know that 'final' has the added constraint of disallowing > > >>>>>> subclassing in the same module, but how useful is that? Does it hold > > >>>>>> its weight? Would we add it now if it did not exist? > > >>>>> > > >>>>> As Matthew says, this is still important. > > >>>>> > > >>>>>> Lazy > > >>>>>> This one is clearer: if Joe Groff's property behaviors proposal from > > >>>>>> last year is brought forward again, lazy can be demoted from a > > >>>>>> language keyword to a Standard Library property behavior. If Joe or > > >>>>>> anybody from the core team sees this: do we have any luck of having > > >>>>>> this awesome feature we discussed/designed/implemented in the Swift > > >>>>>> 4 timeframe? > > >>>>> > > >>>>> Sadly, there is no chance to get property behaviors into Swift 4. > > >>>>> Hopefully Swift 5, but it’s impossible to say right now. > > >>>>> > > >>>>>> Fileprivate > > >>>>>> > > >>>>>> I started the discussion early during the Swift 4 timeframe that I > > >>>>>> regret the change in Swift 3 which introduced a scoped private > > >>>>>> keyword. For me, it's not worth the increase in complexity in access > > >>>>>> modifiers. I was very happy with the file-scope of Swift pre-3. When > > >>>>>> discussing that, Chris Latner mentioned we'd have to wait for Phase > > >>>>>> 2 to re-discuss it and also show proof that people mostly used > > >>>>>> 'fileprivate' and not the new 'private' modifier as proof if we want > > >>>>>> the proposal to have any weight. Does anybody have a good idea for > > >>>>>> compiling stats from GitHub on this subject? First of all, I've > > >>>>>> always found the GitHub Search quite bad and don't know how much it > > >>>>>> can be trusted. Secondly, because 'private' in Swift 2 and 3 have > > >>>>>> different meanings, a simple textual search might get us wrong > > >>>>>> results if we don't find a way to filter on Swift 3 code. > > >>>>> > > >>>>> I would still like to re-evaluate fileprivate based on information in > > >>>>> the field. The theory of the SE-0025 > > >>>>> (https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md) > > >>>>> was that the fileprivate keyword would be used infrequently: this > > >>>>> means that it would uglify very little code and when it occurred, it > > >>>>> would carry meaning and significance. > > >>>> > > >>>> Infrequent use and significance are orthogonal. > > >>>> I still think developers would declare all ivars private (this is less > > >>>> ugly and shorter), and then will happily convert them to fileprivate > > >>>> each time the compiler will tell them they are not accessible > > >>>> somewhere else in the file. > > >>>> As the code that try to access that ivar is in the same file anyway, > > >>>> it has full knowledge of the implementation details and there is no > > >>>> good reason it shouldn’t be able to access the ivar when needed. > > >>>> > > >>>>> We have a problem with evaluating that theory though: the Swift 2->3 > > >>>>> migrator mechanically changed all instances of private into > > >>>>> fileprivate. This uglified a ton of code unnecessarily and (even > > >>>>> worse) lead programmers to think they should use fileprivate > > >>>>> everywhere. Because of this, it is hard to look at a random Swift 3 > > >>>>> codebase and determine whether SE-0025 is working out as intended. > > >>>>> > > >>>>> The best way out of this that I can think of is to add a *warning* to > > >>>>> the Swift 3.1 or 4 compiler which detects uses of fileprivate that > > >>>>> can be tightened to “private” and provide a fixit to do the change. > > >>>>> This would be similar to how we suggest changing ‘var’ into ‘let’ > > >>>>> where possible. Over time, this would have the effect of getting us > > >>>>> back to the world we intended in SE-0025. > > >>>>> > > >>>>> -Chris > > >>>>> > > >>>>> _______________________________________________ > > >>>>> 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 > > >> _______________________________________________ > > >> 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 > > > > _______________________________________________ > 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
