<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="">I'm -1 on that – compiler should guarantee the program correctness, not style correctness.<div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.)</blockquote><div class=""><br class=""></div>I almost immediately thought of whole projects where people would put `@style(hybrid)` at the top to get rid of troublesome compiler warnings, or put the "style exception" annotation for the whole file. This would become "public static void main" of Swift.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.<br class=""></blockquote><br class=""></div><div class="">My greatest concern is about who will define what "bad smell" and individual styles look like. Coding style is a very subjective matter, and should not be enforced by compiler or any manifest (that's why I'm against strict code style guides as well).</div><div class=""><br class=""></div><div class="">Besides, enforcing one style per source file would loose one of the best features of Swift – diversity. Swift is a multi-paradigm language, influenced by the best features of many other modern languages. It is imperative, functional, object-oriented and protocol-oriented at the same time. We'd loose that variety.</div><div class=""><br class=""></div><div class=""><br class=""></div><div apple-content-edited="true" class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Regards,</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Adrian Kashivskyy</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">iOS Developer at Netguru</div>
</div>

<br class=""><div><blockquote type="cite" class=""><div class="">Wiadomość napisana przez Amir Michail &lt;<a href="mailto:amichail@gmail.com" class="">amichail@gmail.com</a>&gt; w dniu 05.12.2015, o godz. 00:53:</div><br class="Apple-interchange-newline"><div class=""><div class="">Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.) and code that doesn’t match that style would result in a compiler error.<br class=""><br class="">For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.<br class=""><br class="">If you don’t want to fix the problem, you could use a style exception construct to surround the code in question and it would get rid of the compile error.<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>