[swift-evolution] Enforcing guidelines

[Jason Dusek]

What if there were a kind of quoting for non-conforming names? For example,
instead of:

PQlibVersion()

one writes:

`PQlibVersion`()

This would have the effect of marking out non-conforming, weird code
explicitly.

(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.)

Best Regards,
Jason Dusek

On Fri, 11 Dec 2015 at 13:14, Douglas Gregor via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>
> But, nobody has signed up to design/implement a warning
> opt-in/opt-out/escalation mechanism for the Swift compiler.
>
> - Doug
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/4d8fc90b/attachment.html>