<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="">Le 7 avr. 2017 à 13:44, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">No. I believe it makes the language worse, not better. It doesn’t address the real problems with access control. The largest problem is the inability to form scopes between files and the entire module. The problem with `fileprivate` and `private` is a naming problem, not a semantics problem.</div></div></blockquote><br class=""></div><div>This is the base of your argument, and I think it is wrong, considering that code is a living matter, not a static one.</div><div><br class=""></div><div>Too many properties initially declared as `private` have to be declared `fileprivate` later, because the code is evolving. And this change is usually performed just to tame a compiler error.</div><div><br class=""></div><div>This is why the current private/fileprivate situation is actually a semantics problem. Private is not stable enough to mean anything.</div><div><br class=""></div><div>Gwendal Roué</div><div><br class=""></div></body></html>