I find the final keyword useful when I want to communicate that this class should not be subclassed.
I think the behavior should remain the same since it is useful. On Sun, Feb 12, 2017 at 5:15 PM Matthew Johnson via swift-evolution < [email protected]> wrote: > On Feb 12, 2017, at 3:52 PM, Xiaodi Wu <[email protected]> wrote: > > On Sun, Feb 12, 2017 at 3:47 PM, Matthew Johnson <[email protected]> > wrote: > > > On Feb 12, 2017, at 3:45 PM, Xiaodi Wu <[email protected]> wrote: > > On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson <[email protected]> > wrote: > > > On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution < > [email protected]> 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. > > > It wasn't a rhetorical question that I asked: what value do you perceive > in the new `private` in terms of helping you reason through code? > > > You are right that any time it really matters it’s not hard to answer the > question with a search, so it’s largely a convenience. > > That said, I find it quite useful to be able to mark helper methods and > types within an extension `private` to make it clear that they are indeed > local helper methods or types that are not accessed more broadly. This > communicates an intent. As long as your extensions don’t get too large, a > whole extension is usually visible on a single screen on a 27” iMac which > is very useful - you don’t have to consider code that is scrolled out of > sight. > > I also find it useful to be able to mark stored properties `private` and > therefore *not* available to extensions. This can facilitate tighter > encapsulation of state, especially when there is a handful of basis methods > through which the extensions access that state. > > > 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 <[email protected]> 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 <[email protected]> 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 < > [email protected]> wrote: > > Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution < > [email protected]> a écrit : > > On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
