<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="">On Dec 5, 2015, at 12:54 PM, Alex Blewitt via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPhat 6</div><div class=""><br class="">On 5 Dec 2015, at 19:23, Adrian Kashivskyy <<a href="mailto:adrian.kashivskyy@me.com" class="">adrian.kashivskyy@me.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class="">SwiftLint looks really nice, but one thing I'd really like is automatic formatting.</div></div></blockquote><div class=""><br class=""></div>That's a feature of IDE, not the language itself.</div></blockquote><div class=""><br class=""></div>Not necessarily. The existence of "go fmt" has resulted in teams running it as a pre-commit translation and as a way of standardising across all users, regardless of IDEs. Otherwise you end up with multiple IDEs (like Eclipse and IntelliJ) which do formatting slightly differently and lead to all manner of pointless arguments. <div class=""><br class=""></div><div class="">Letting "the IDE" do formatting is fine provided there is a maximum of one IDE. </div></div></div></blockquote><br class=""></div><div>Just to chime in on this thread with some guidelines for thought:</div><div><br class=""></div><div>1) The compiler does have some code smell warnings (e.g. unmutated var -> let).</div><div>2) It is really important that these be warnings, not errors. Turning them into errors makes refactoring code a pain (as commonly complained about in the go community).</div><div>3) By doing these sorts of things, the compiler needs to be conservative in its policies - the policies that it enforces has to be unquestionably the right thing to do.</div><div><br class=""></div><div>Separate from compiler-enforced policies, I’d *love* to see someone tackle implementing a "go fmt” analog that reformats Swift code into a standard style, as well as a “clang format” tool that could be used by IDEs for on-the-fly editing of code, as well as a “linter” / static analysis tool which can flag potential issues while having a higher tolerance for false positives. These should be separate from the “always on” compiler diagnostics though.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>