<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I would like to separately concur with (most of) Matt's excellent review. He identifies what I think the core issues here, which are</div><ul><li>People code in different styles. A scoped keyword is more useful in some styles and less useful in others, and this debate is in many ways a proxy war about programming style.</li><li>Most of the "solutions" proposed boil down to telling private users to adopt a different programming style. Instead we should be making Swift a great language for a *wider* diversity of programming styles as it expands to new platforms and solves new problems.</li><li>The complexity argument seems weak or even absent. It consists largely of the informal observation that 3 keywords are better than 4, which may "feel true" but does not have the research behind it of a Goto Considered Harmful™. Instead, most of the research on usage and impact are coming from those trying to keep it, which does not seem like their burden to meet.</li></ul><p class="airmail_on">On March 23, 2017 at 1:22:49 AM, Matt Gallagher via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>> What is your evaluation of the proposal?<br><br>I disagree with this proposal. It removes functionality that I actively use.<br><br>This proposal aims to revert SE-0025 without really addressing the aims of that proposal, merely dismissing the result as "actively harmful" without defining what that means. SE-0159 raises the complaint that "private" is syntactically more natural default while "fileprivate" is a more useful default. On this point, I agree but the proposal is not about mere renaming.<br><br>The other discussion in the proposal is to ask the questions:<br><br> 1. is that distinction between private and fileprivate actively used by the larger community of Swift developers<br><br> 2. if it were used pervasively, would it be worth the cognitive load and complexity of keeping two very similar access levels in the language?<br><br>Fair questions but despite the proposal claiming "This proposal argues that answer to both questions is no", the proposal offers no *arguments* for the answers, it merely states a position.<br><br>For this reason, I feel the proposal is unreasonably dismissive of the aims of SE-0025.<br><br>Frankly, both these questions have subjective answers based on how programmers tend to design their programs. I personally like to build functionality using lots of very tiny types (many just 4 or 5 lines long), therefore, I frequently put multiple types in the same file (they're part of the same functionality, even if they're not part of the same type). However, I want to have actual interfaces and implementation hiding between them otherwise there's always the possibility of accidentally abusing the interface to each type. An access modifier narrower than the file, like the current scoped "private", is the *only* way to achieve this.<br><br>Reverting SE-0025 means the only way to have enforced interfaces between types is to place them in separate files. This is counterproductive for tiny types that form a single conceptual entity. Separate files also requires whole-program optimization for optimal performance.<br><br>The only conclusion I can make is that programmers in favor of this proposal simply don't program this way. However, I find it insulting that this proposal is essentially saying: your way of designing and structuring programs is wrong; you must use big monolithic types in their own files and endure reduced compilation (whole-program optimization) or runtime performance (no inlining between files with whole-program off).<br><br>I can't help but feel that this proposal is really misdirected frustration. Programmers who don't use clusters of tiny types in a single file shouldn't care about the existence of a scoped access modifier because it shouldn't affect them – they should use file access modifiers and be done. Yet apparently, it is file access modifier advocates pushing this proposal.<br><br>It really seems like the existence of a scoped access modifier is taking the blame for people's frustration that the simpler keyword ("private") is a less good default than the clunky keyword ("fileprivate"). I personally agree that the behavior or "fileprivate" is probably a better default so I understand the desire to give "private" back that meaning again. However, I don't want to lose a scoped access modifier because it is *useful* (for reasons of both project structure and compilation or runtime performance).<br><br>So... thumbs down from me. However, if someone wants to rename fileprivate -> private and rename private -> scope (or something) I'd be more supportive.<br><br>Regards,<br>Matt Gallagher.<br><br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></body></html>