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. 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
