<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=""><div class="">I use this access control model. As I usually split large classes into multiple files using extensions, marking members "fileprivate" or "private" initially is pointless.</div><div class=""><br class=""></div><div class="">Of course, "private" can be used for small classes which don't need to be split, but that would be inconsistent. Also the code looks tidy without being cluttered with "private" in every declaration.</div><div class=""><br class=""></div><div class="">It's too bad that compiler can't protect classes inside the same module from accessing implementation details of other classes using this approach, but I sacrificed this for freely splitting code between files. Imo, ideal access model for this coding style would be "type+extensions" visibility default with explicit "module" ("internal") and "public" modifiers.</div><div class=""><br class=""></div><div class="">Andrey</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 17 Apr 2017, at 14:17, Tino Heth 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I don't remember the exact location, but there have been several contributions from active members of the community who stated they would be fine with just two levels of access control — but I haven't seen this standpoint discussed at all.<div class="">Most likely, that is because it contradicts the perceived spirit on swift-evolution, but who knows, maybe this opinion isn't as isolated as we think?</div><div class="">To be honest, I don't expect that such a drastic simplification would be seriously considered, but I think it's a good exercise to take such an extreme perspective.</div><div class=""><br class=""></div><div class="">[If anyone would like to participate in this experiment, you may prefer to skip the rest for now to avoid bias ;-) ]</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">[personal results start here]</div><div class=""><br class=""></div><div class="">I don't need access control as a tool to enforce my opinion onto others, so I'm not generally opposed to a compiler-orientated model, where access limitation would only be used to allow better optimisation.</div><div class=""><br class=""></div><div class="">What I don't want to loose is a way to document intensions which helps users of an API — but this could be something different than a compilation error that tells me I'm trying to call a method that I'm not allowed to use.</div><div class="">In my day to day routine, the language level actually isn't that important:</div><div class="">When I work in an environment that is new to me, a method that is missing in autocompletion is as protected as a private member, and it's similar for overrides.</div><div class="">So I would be fine with a set of annotations that are ignored by the compiler, but used by the IDE. Actually, such an approach could have saved me from stupid errors in the past, because the compiler only knows if I'm allowed or forbidden to do something (anyone else ever had fun with <span style="color: rgb(36, 39, 41); font-family: Consolas, Menlo, Monaco, 'Lucida Console', 'Liberation Mono', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Courier New', monospace, sans-serif; font-size: 13px; white-space: pre-wrap; background-color: rgb(239, 240, 241);" class="">UITableView.didDeselectRowAtIndexPath</span><span style="white-space: pre-wrap;" class="">? Alphabetical order is a really inconvenient sometimes, and there is no way for the compiler to detect such problems reliably).</span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>