<div dir="ltr">On Wed, Jan 25, 2017 at 4:34 PM, Robert Widmann <span dir="ltr"><<a href="mailto:devteam.codafi@gmail.com" target="_blank">devteam.codafi@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Responding on the pro side, but I don't endorse this proposal without more details:<br><br>~Robert Widmann</div><div><br>2017/01/25 13:40、Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> のメッセージ:<br><br></div><span class=""><blockquote type="cite"><div>This is contrary to several deliberate design decisions, if I understand correctly.<br><br>First, revisions to visibility rules in the Swift 3 timeline were made with the deliberate intention that it should be possible to model greater visibility within a type (e.g. public members) without actually exporting that type. As Swift does not have optional warnings that can be turned off, it would be incongruous if the language also warned users away from creating internal types or variables before they are used. Unlike warnings about unused variables within a scope, which are by definition local, a warning such as proposed would be much more disruptive.<br></div></blockquote><div><br></div></span><div>That decision wasn't really one made to support a deliberate design, but to help make migration of fileprivate easier IIRC (Jordan Rose probably remembers better than I do of the conversation we had about this).</div><div><br></div><div>It's important to note we already provide module-wide warnings (namely if we detect you mutating a let-bound member we offer a fixit at the site of the member decl) so this isn't new.</div><span class=""><br><blockquote type="cite"><div><br>Second, a variable with no access modifier defaults to internal, and this is deliberate for the purpose of progressive disclosure (i.e. it is, by design, possible for a new user to write useful code separated across multiple files without learning what access modifiers are). This would be undone if nearly every such use prompted a warning.<br></div></blockquote><div><br></div></span><div>That enforces hiding from clients, OP wants to enforce a model where we enforce data hiding from yourself as well. If a variable's access needs to be escalated we can provide that fixit as well (instead of the current errors we offer now which are usually spurious type errors because lookup barfs).</div></div></blockquote><div><br></div><div>Sure, the motivation is not ambiguous.</div><div><br></div><div>In the past, when new syntax for yet another access level has been proposed, I've argued that perfect data hiding from yourself (as opposed to clients) has been a non-goal (given the access levels available today) and probably should continue to be. There's been disagreement about that--fine.</div><div><br></div><div>But _enforcing_ data hiding from yourself as The One True Way of Swift is something else. Though not technically *source* breaking for existing code, it is certainly radically design breaking. Far from being a bugfix, I'd argue that such a change is big enough to merit one of those manifesto-style big-picture discussions, and I'd want to be convinced of huge wins for such a U-turn in direction.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><blockquote type="cite"><div>In summary, I think the issue here is more one of style than safety, and IMO is more within the scope of a linter.<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 25, 2017 at 12:27 Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="m_2798541396228381841gmail_msg"><div class="m_2798541396228381841gmail_msg">So, to be clear, a warning about making internal variables more private based on their usage in the entire module? </div><div id="m_2798541396228381841m_-4942221354445230965AppleMailSignature" class="m_2798541396228381841gmail_msg"><br class="m_2798541396228381841gmail_msg"></div><div id="m_2798541396228381841m_-4942221354445230965AppleMailSignature" class="m_2798541396228381841gmail_msg">Sounds doable. Probably wouldn't need to go through evolution to get it too (but I'll let others make that call). Please file an SR about this too.<br class="m_2798541396228381841gmail_msg"><br class="m_2798541396228381841gmail_msg">~Robert Widmann</div><div class="m_2798541396228381841gmail_msg"><br class="m_2798541396228381841gmail_msg">2017/01/25 3:25、Dave Kliman via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_2798541396228381841gmail_msg" target="_blank">swift-evolution@swift.org</a>> のメッセージ:<br class="m_2798541396228381841gmail_msg"><br class="m_2798541396228381841gmail_msg"></div></div><div dir="auto" class="m_2798541396228381841gmail_msg"><blockquote type="cite" class="m_2798541396228381841gmail_msg"><div class="m_2798541396228381841gmail_msg">Hi!<div class="m_2798541396228381841gmail_msg"><br class="m_2798541396228381841gmail_msg"></div><div class="m_2798541396228381841gmail_msg">I’m somewhat new to swift, so this issue may have been covered.</div><div class="m_2798541396228381841gmail_msg"><br class="m_2798541396228381841gmail_msg"></div><div class="m_2798541396228381841gmail_msg">I really like how I get a warning for variables I’ve declared, but have not mutated, or constants that I did not read.</div><div class="m_2798541396228381841gmail_msg"><br class="m_2798541396228381841gmail_msg"></div><div class="m_2798541396228381841gmail_msg">What about warnings for anything not accessed outside its declared scope, encouraging the use of <i class="m_2798541396228381841gmail_msg">private</i>, or <i class="m_2798541396228381841gmail_msg">fileprivate</i> more often?</div><div class="m_2798541396228381841gmail_msg"><br class="m_2798541396228381841gmail_msg"></div><div class="m_2798541396228381841gmail_msg">-Dave</div></div></blockquote><blockquote type="cite" class="m_2798541396228381841gmail_msg"><div class="m_2798541396228381841gmail_msg"><span class="m_2798541396228381841gmail_msg">______________________________<wbr>_________________</span><br class="m_2798541396228381841gmail_msg"><span class="m_2798541396228381841gmail_msg">swift-evolution mailing list</span><br class="m_2798541396228381841gmail_msg"><span class="m_2798541396228381841gmail_msg"><a href="mailto:swift-evolution@swift.org" class="m_2798541396228381841gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="m_2798541396228381841gmail_msg"><span class="m_2798541396228381841gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="m_2798541396228381841gmail_msg" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br class="m_2798541396228381841gmail_msg"></div></blockquote></div>______________________________<wbr>_________________<br class="m_2798541396228381841gmail_msg">
swift-evolution mailing list<br class="m_2798541396228381841gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_2798541396228381841gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_2798541396228381841gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_2798541396228381841gmail_msg" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br class="m_2798541396228381841gmail_msg">
</blockquote></div>
</div></blockquote></span></div></blockquote></div><br></div></div>