Daryle, there have been several pitches in the past with respect to #error, and very enlightening arguments both for and against the idea have been eloquently written.<br><br>Since you’re resurrecting this idea, could I suggest going back through the archives and linking to and summarizing these arguments, so that we’re not restarting the discussion from scratch? :)<br><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Jun 10, 2017 at 13:26 Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Love it! Except I'd add `warning` as well.</div><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Jun 10, 2017, at 8:15 PM, Daryle Walker via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_4124845257621492720Apple-interchange-newline"><div><div style="word-wrap:break-word"><h1 id="m_4124845257621492720toc_0" style="margin:0px 0px 10px;padding:0px;font-size:28px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Unconditional Error Messages</h1><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><li style="margin:0px">Proposal: <a style="color:rgb(65,131,196);margin-top:0px">SE-NNNN</a></li><li style="margin:0px">Authors: <a href="https://github.com/CTMacUser" style="color:rgb(65,131,196);margin-top:0px" target="_blank">Daryle Walker</a>, <a href="https://github.com/swiftdev" style="color:rgb(65,131,196)" target="_blank">Author 2</a></li><li style="margin:0px">Review Manager: TBD</li><li style="margin:0px">Status: <strong style="margin-top:0px">Awaiting review</strong></li></ul><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><em>During the review process, add the following fields as needed:</em></p><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><li style="margin:0px">Decision Notes: <a href="https://lists.swift.org/pipermail/swift-evolution/" style="color:rgb(65,131,196);margin-top:0px" target="_blank">Rationale</a>, <a href="https://lists.swift.org/pipermail/swift-evolution/" style="color:rgb(65,131,196)" target="_blank">Additional Commentary</a></li><li style="margin:0px">Bugs: <a href="https://bugs.swift.org/browse/SR-NNNN" style="color:rgb(65,131,196);margin-top:0px" target="_blank">SR-NNNN</a>, <a href="https://bugs.swift.org/browse/SR-MMMM" style="color:rgb(65,131,196)" target="_blank">SR-MMMM</a></li><li style="margin:0px">Previous Revision: <a href="https://github.com/apple/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank">1</a></li><li style="margin:0px">Previous Proposal: <a style="color:rgb(65,131,196);margin-top:0px">SE-XXXX</a></li></ul><h2 id="m_4124845257621492720toc_1" style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Introduction</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">This proposal adds the <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">#error</code> directive, which unconditionally posts a compile-time error.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Swift-evolution thread: <a href="https://lists.swift.org/pipermail/swift-evolution/" style="color:rgb(65,131,196)" target="_blank">Discussion thread topic for that proposal</a></p><h2 id="m_4124845257621492720toc_2" style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Motivation</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">A conditional compilation block permits branches of code based on the compilation conditions.</p><div style="font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><pre style="margin-top:15px;margin-bottom:15px;background-color:rgb(248,248,248);border:1px solid rgb(204,204,204);font-size:13px;line-height:19px;overflow:auto;padding:6px 10px;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px"><code class="m_4124845257621492720language-none" style="margin:0px;padding:0px;border:none;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">#if compilation condition 1
// statements to compile if compilation condition 1 is true
#elseif compilation condition 2
// statements to compile if compilation condition 2 is true
#else
// statements to compile if both compilation conditions are false
#endif</code></pre></div><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">A block lets at most one of its branches to be incorporated into the compiled module. But compilation always occurs; there is no scenario to flag conditions that should never allow compiling.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">When suspending work on a source file for a while, marking where you ended work with an unconditional error message would let the compiler remind you where you left off.</p><h2 id="m_4124845257621492720toc_3" style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Proposed solution</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">The solution is to add a new compiler control statement, one that posts a fatal diagnostic during compilation. It can include a message to aid the user on how to change their code.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">It's called <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">#error</code>, after the C preprocessor directive that has the same effects.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">For example, instead of checking API compatibility at run-time:</p><div style="font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><pre style="margin-top:15px;margin-bottom:15px;background-color:rgb(248,248,248);border:1px solid rgb(204,204,204);font-size:13px;line-height:19px;overflow:auto;padding:6px 10px;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px"><code class="m_4124845257621492720language-none" style="margin:0px;padding:0px;border:none;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">guard #available(tvOS 1.0, *) else {
fatalError("We need a TV.")
}
// Do what we're supposed to do....</code></pre></div><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">We can move the check to compile-time:</p><div style="font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><pre style="margin-top:15px;margin-bottom:15px;background-color:rgb(248,248,248);border:1px solid rgb(204,204,204);font-size:13px;line-height:19px;overflow:auto;padding:6px 10px;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px"><code class="m_4124845257621492720language-none" style="margin:0px;padding:0px;border:none;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">#if os(tvOS)
// Do what we're supposed to do....
#else
#error("We need a TV.")
#endif</code></pre></div><h2 id="m_4124845257621492720toc_4" style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Detailed design</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Add to the "Grammar of a Compiler Control Statement":</p><blockquote style="margin:15px 0px;border-left-width:4px;border-left-style:solid;border-left-color:rgb(221,221,221);padding:0px 15px;color:rgb(119,119,119);font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><div style="margin:0px"><em>compiler-control-statement</em> → <em>error-directive-statement</em></div></blockquote><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Add a new section "Grammar of a Error Directive Statement":</p><blockquote style="margin:15px 0px;border-left-width:4px;border-left-style:solid;border-left-color:rgb(221,221,221);padding:0px 15px;color:rgb(119,119,119);font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><div style="margin:0px"><em>error-directive-statement</em> → <strong>#error</strong> <strong>(</strong> <em>static-string-literal</em> <strong>)</strong></div></blockquote><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">The semantics of an error directive statement are: when such a statement is encountered during translation, and it is not in an inactive compilation block branch, compilation is aborted and the directive's string is included in the diagnostic of the directive's source line.</p><h2 id="m_4124845257621492720toc_5" style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Source compatibility</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">This proposal should cause no problems with source compatibility. Relative to the current grammar, there is an addition of one token: <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">#error</code>. Since #-leading tokens are illegal except for the explicitly defined ones, there is no possibly of token overlap in legacy code.</p><h2 id="m_4124845257621492720toc_6" style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Effect on ABI stability</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Since the domain of this proposal is all in the compilation phase of creating object code, there is no effect on ABI stability.</p><h2 id="m_4124845257621492720toc_7" style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Effect on API resilience</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">The domain of this proposal, controlling whether translation completes, does not affect any API.</p><h2 id="m_4124845257621492720toc_8" style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Alternatives considered</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">The alternative is to do nothing. This would mean any checks would stay being delayed into run-time, and calling <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">fatalError</code> or similar functions to avoid implementing uncovered compilation cases.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">The original C syntax left open tokens as the message after the <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">#error</code> token. I decided to enclose the message as a string to ease parsing.</p><h2 id="m_4124845257621492720toc_9" style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Future directions</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">The original idea for this proposal was a distraction while bringing an adaptation of C++'s <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">static_assert</code>, as defined in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html" style="color:rgb(65,131,196)" target="_blank">its proposal</a>. The <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">static_assert</code> is a condition-checking mechanic between <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">assert</code> and <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">#error</code>; Swift already has the former and this proposal would bring the latter. There'd still be no equivalent for <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">static_assert</code>. Another proposal for non-environment compile-time expressions and their use in generic where clauses would relieve most of need for <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">static_assert</code>, but there needs to be either a new construct a declaration-level version or <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">#if</code>/<code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">#elseif</code> need to be allowed to access non-environment compile-time expressions.</p><h2 id="m_4124845257621492720toc_10" style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Acknowledgements</h2><ul style="margin-top:15px;margin-right:0px;margin-left:0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255);margin-bottom:0px!important"><li style="margin:0px"><a href="https://barrgroup.com/embedded-systems/how-to/c-preprocessor-error-directive" style="color:rgb(65,131,196);margin-top:0px" target="_blank">How to Use the C Preprocessor's #error Directive</a> by Nigel Jones</li></ul><div><br></div><div>
<div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word;line-break:after-white-space"><div>— </div><div>Daryle Walker<br>Mac, Internet, and Video Game Junkie<br>darylew AT mac DOT com </div></div>
</div>
<br></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>