<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The way I see it and would use it:<div class=""><br class=""></div><div class="">Directives:</div><div class=""><br class=""></div><div class=""><b class="">#error</b> - fatal error, the binary shouldn't compile - e.g. unknown OS host and the code depends on underlying OS features.</div><div class=""><br class=""></div><div class=""><b class="">#warning</b> - it is a big deal, but allow the binary to compile for testing. E.g. you know some feature isn't implemented yet and you want a warning so that you don't forget to implement it before releasing it to the public. Or as someone has mentioned (I have used #warning like this as well), have a warning for internal builds so that you don't accidently upload an internal build to AppStore (happened to me more than once).</div><div class=""><br class=""></div><div class="">Comments:</div><div class=""><br class=""></div><div class=""><b class="">TODO</b> - something that would enhance or improve the app, but the current behavior is sufficient for release. E.g. "TODO - refactor this code", "TODO - think of a better name for this function" - it's not fatal, crucial to the app, but is "nice to have".</div><div class=""><br class=""></div><div class=""><b class="">FIXME</b> - place in code that is known to underperform or fail in certain situations, but these situations are rather rare and aren't critical. E.g. "FIXME - when there are 20 000 rows in this table view, it is slow", "FIXME - when run from a read-only volume, this behaves weirdly".</div><div class=""><br class=""></div><div class="">One may argue that the comment-based markings can be handled by the IDE, but IMO transferring language features onto IDE is wrong. These comments do not appear anywhere within the log when the code is compiled.</div><div class=""><br class=""></div><div class="">Comments are IMO "silent/soft" warnings that are good to go through when you have nothing else to do and look for a way to fix minor issues within the app. But when you get those mixed with larger issues such as "missing feature, do not release without it!", you can get a long list and not notice the important ones on that list. Not to mention you need to currently search for these manually each time.</div><div class=""><br class=""></div><div class="">Charlie</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class="">On May 30, 2016, at 10:57 PM, Christopher Kornher via swift-evolution <swift-<a href="mailto:evolution@swift.org" class="">evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On May 30, 2016, at 2:35 PM, Chris Lattner via swift-evolution <swift-<a href="mailto:evolution@swift.org" class="">evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On May 29, 2016, at 10:36 PM, Charlie Monroe <<a href="mailto:charlie@charliemonroe.net" class="">charlie@charliemonroe.net</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">As to #warning, Swift’s use of warnings are significant different than the use in C. In C compilers, many of the warnings produced *should* be errors, but can’t be because that effects language conformance and could break a large body of code. <br class=""></blockquote><br class="">The example I've mentioned with #error, doesn't necessarily lead to an error, but can just issue a #warning("Untested OS, proceed carefully.") - it IMHO doesn't necessarily be fatal.<br class=""></blockquote><br class="">This doesn’t make sense to me. If the code is untested, then it should definitely be audited and check if it is enabled. A #error is the perfect approach for this case.<br class=""></blockquote><br class="">I have used warnings in other languages when “bringing-up” large code bases. Using a #warning facility is helpful at these times. Counting the messages provides a metric for unresolved questions. I don’t fully understand Chris’s objection to a warning compiler directive, so I cannot comment on that. A ‘Mark’ - like comment format would be almost as good.<br class=""><br class="">There is a problem with ‘magic’ comment formats, though. Recently I have had issues with mistyping “// MARK”. IIRC, “// mark” is not recognized. Compiler directives do not have this problem. In Objective-C “#pragma marl" is a compiler error. In swift, “// MARL” is silently treated as a plain comment.<br class=""><br class=""><br class=""><blockquote type="cite" class="">-Chris<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=""></blockquote><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=""></blockquote><br class=""></div></body></html>