> On Feb 12, 2017, at 3:45 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>> wrote: > >> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto: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.
This is really subjective and it’s not clear to me that there is substantial evidence one way or another. I know that `private` is valued and used heavily by the teams I have worked with. Maybe that’s an exception, but maybe not. I don’t think we know yet and I think this is what Chris is hoping to learn. > >> On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <sa...@nondot.org >> <mailto: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 >> <mailto: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 <mailto:swift-evolution@swift.org>> wrote: >>>> Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >>>> >>>> On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution >>>> <swift-evolution@swift.org <mailto: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 >>>> >>>> <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 <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
