[swift-evolution] Enforcing guidelines

[Douglas Gregor]

> On Dec 11, 2015, at 1:40 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>>> 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:
>>> 
>>> "Follow case conventions: names of types, protocols and enum cases are UpperCamelCase. Everything else is lowerCamelCase.”
>>> 
>>> 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.
>> 
>> 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).
>> 
>> I’d also suggest that this produce a warning for violations, not an error.
> 
> Does Swift have a general policy that it should be possible to silence any warning the compiler emits?

We should have such a policy, and Clang’s approach to handling warnings is a fairly good model:

	http://clang.llvm.org/docs/UsersManual.html <http://clang.llvm.org/docs/UsersManual.html>

But, nobody has signed up to design/implement a warning opt-in/opt-out/escalation mechanism for the Swift compiler.

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/405e218a/attachment.html>