What if there were a kind of quoting for non-conforming names? For example, instead of:<br><br>PQlibVersion()<br><br>one writes:<br><br>`PQlibVersion`()<br><br>This would have the effect of marking out non-conforming, weird code explicitly.<br><br>(It might be the case that only a single leading backtick, in the manner of Lisp quoting, is better in practice; and I don't know enough about the grammar of Swift to say that backtick is the best choice.)<br><br>Best Regards,<br> Jason Dusek<br><br><div class="gmail_quote"><div dir="ltr">On Fri, 11 Dec 2015 at 13:14, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org">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 style="word-wrap:break-word"><div><blockquote type="cite"><div>On Dec 11, 2015, at 1:40 AM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div><blockquote type="cite"><blockquote type="cite">Has any thought been given to making some of the design guidelines required by the compiler, instead of just guidelines? One guideline in particular I am thinking of is:<br><br>"Follow case conventions: names of types, protocols and enum cases are UpperCamelCase. Everything else is lowerCamelCase.”<br><br>As a teacher, I have to remind my students of this convention several times a day, mostly because students learn and use different languages (with different conventions) at the same time. After nil unwrapping, inconsistent casing is probably the #2 source of bugs my students write.<br></blockquote><br>I think we’d have to carefully consider the exact policies that we support out of the box, but I’m not completely opposed to this sort of feature. It should also only apply to declarations, not uses of values (e.g. you should be able to “use” a misnamed decl imported from a C header).<br><br>I’d also suggest that this produce a warning for violations, not an error.<br></blockquote><br>Does Swift have a general policy that it should be possible to silence any warning the compiler emits?<br></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>We should have such a policy, and Clang’s approach to handling warnings is a fairly good model:</div><div><br></div><div><span style="white-space:pre-wrap"> </span><a href="http://clang.llvm.org/docs/UsersManual.html" target="_blank">http://clang.llvm.org/docs/UsersManual.html</a></div><div><br></div><div>But, nobody has signed up to design/implement a warning opt-in/opt-out/escalation mechanism for the Swift compiler.</div><div><br></div></div><div><span style="white-space:pre-wrap"> </span>- Doug</div><div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=kKLYQ91ZFOe6ryzRU3CXyiq4yOweT6LjPwa6z8Qwa5fst3gzFL7sfW4v40C-2F9Ody-2FIbljBNHGQfyIIfv5wxYW7MKXqQ-2Bz-2FbWPkJ2Z015I7KyDHyV2CmL2OmzmOqbqwcm7iK7Cb8cKVJ066bjVDjZaOFqCXG7qc29IDI5oQh84k5lbtJW8xc1bkSPRN0tzFFCMt-2FOAlFrt6Yl-2BT7lZjRLwxLZlYwxX1Tbh4XyDMYKqQ4-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>