<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 12, 2017, at 10:34 AM, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 12, 2017, at 5:19 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class="">I was reading this nice listing of Swift keywords (<a href="https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh" class="">https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh</a>) and three of them struck me as potentially not long for this world and I was thinking if we needed/could deprecate them before any kind of ABI stability set in.<div class=""><br class=""></div><div class="">I'm listing them here but it might be worth starting separate discussions for each of them.<br class=""><div class=""><br class=""></div><div class=""><b class="">Final</b></div><div class=""><br class=""></div><div class="">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?</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">To me, it's useful a lot. The module doesn't necessarily be a 1KLOC framework - I've been recently refactoring a 90KLOC module and the final keyword was fairly useful since some subclasses used hacks by overriding some vars or methods. This allowed me to look at it from a different perspecitve, make some members final and create better API endpoints for customization.</div><div class=""><br class=""></div><div class="">Not to mention that it allows the compiler to access stored properties directly when they're final - if I recall correctly someone from the core team mentioning that.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""><div class=""><br class=""></div><div class=""><b class="">Lazy</b></div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class=""><b class="">Fileprivate</b> </div><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I like the scoped access, I actually find it useful when declaring several classes within one file, so that I know I'm not accessing that class' private members. That said, I agree that the change to fileprivate was IMHO a mistake - aside from the fact that I dislike the fileprivate keyword, I was more leaning towards the idea that fileprivate would be default for private and when someone really wants to make some member scope-private, private(scope) could be used.</div></div></div></div></blockquote><div><br class=""></div><div>I also like the scoped access control but think we probably made a mistake in the choice of keywords. The problem was that nobody could come up with a name for specifying scoped access that had broad consensus. I hope that if somebody identifies a really obviously good keyword for scoped access that we might consider making a breaking change to fix this problem. But I think it would have to be very clearly better, and even then may not provide enough benefit to justify a breaking change.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""><br class=""></div><div class="">Thanks for hearing me out!</div><div class=""><br class=""></div><div class="">David.</div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>