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