<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></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 Mar 23, 2017, at 1:22 AM, Matt Gallagher 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=""><div class=""><blockquote type="cite" class="">What is your evaluation of the proposal?<br class=""></blockquote><br class="">I disagree with this proposal. It removes functionality that I actively use.<br class=""><br class="">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 class=""><br class="">The other discussion in the proposal is to ask the questions:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>1. is that distinction between private and fileprivate actively used by the larger community of Swift developers<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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 class=""><br class="">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 class=""><br class="">For this reason, I feel the proposal is unreasonably dismissive of the aims of SE-0025.<br class=""><br class="">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 class=""><br class="">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 class=""><br class="">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 class=""><br class="">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 class=""><br class="">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 class=""><br class="">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 class=""></div></div></blockquote><div><br class=""></div><div>Huge +1 to everything Matt says here. </div><div><br class=""></div><div>Elsewhere it has been argued that submodules allowing for a submodule scope can be combined with file scope to address some of the use cases for scoped access control. This is true, but I want to point out that this combination most definitely <i class="">does not</i> address the use cases Matt describes here. I often also create small types which are in the same file with other types and benefit from scoped access control. As Matt points out, there simply isn’t any other way to address this use case. It would be a shame to see Swift revert to not properly supporting this style of code.</div><div><br class=""></div><div>It is also true that submodules (depending on their design) can address some of the use cases for file level scope. In fact some people have suggested we might be able to drop file level scope after introducing submodules. I wouldn’t want to see us do that (both are useful), but forced to choose between file scope and lexical scope in a language with submodules I may well choose lexical scope. </div><div><br class=""></div><div>Even if we assume that we want to eliminate either file or lexical scope I think it is preliminary to make a decision about which to eliminate. The community should make this decision when we know what submodules look like and what kind of use cases they will address well, address (but maybe not so well) and not address at all.</div><div><br class=""></div><div>If we feel compelled to make a change now we should choose to change the keywords. This will make most or all of the proponents of scoped access happy. It also solves the most prominent problem with `fileprivate` (its ungainly name). My impression is that some people really want to ban scoped access but others just want to be able to use `private` to refer to file scope. The second camp would also be happy with renaming. Two camps would be happy with this approach while a third probably wouldn’t.</div><div><br class=""></div><div>Another argument in support of renaming is that scoped access was originally proposed as introducing a new keyword and leaving private alone. One primary reason this approach was abandoned is that there was no consensus as to what the keyword for scoped access should be. As far as I can tell, consensus has now formed that if we rename it we should simply call it `scoped`. I suspect that if we had chosen this approach originally there would be far less complaints and we probably would not be reviewing a proposal to revert it. This change would better align the language with the original intent of the proposal and address the biggest complaint about fileprivate.</div><div><br class=""></div><div>We could choose to make this change in Swift 4. We could also choose to maintain the status quo in Swift 4 and address access control and submodules in the future as part of a cohesive theme for a Swift release. I would be happy with either choice. I would be extremely disappointed if it was decided that the use cases addressed by scoped access are not important enough to be solved by a language feature and instead relegated to naming conventions and linters.</div><div><br class=""></div><div>Matthew</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Regards,<br class="">Matt Gallagher.<br class=""><br class="">_______________________________________________<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></div></blockquote></div><br class=""></body></html>