> On Feb 12, 2017, at 10:34 AM, Charlie Monroe via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Feb 12, 2017, at 5:19 PM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I was reading this nice listing of Swift keywords >> (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh >> >> <https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh>) >> 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. >> >> I'm listing them here but it might be worth starting separate discussions >> for each of them. >> >> 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? > > 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. > > 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. > >> >> 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? >> >> 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 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.
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. > >> >> Thanks for hearing me out! >> >> David. >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto: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
