<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 9:09 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Mar 24, 2016 at 11:49 AM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
> On Thu, Mar 3, 2016 at 10:40 AM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> That was what I meant by "justification". I would say it has to be<br>
>> reasonably compelling code (win32 headers, boost, some other major<br>
>> library) as that's our usual bar for these sort of bug-for-bug<br>
>> compatible things, as I understand it.<br>
><br>
><br>
> I'd rather apply this patch now than wait for ffmpeg or someone to try to<br>
> use static_assert and then have to hustle to get this into clang. Many many<br>
> C projects have COMPILE_ASSERT macros that are just a small change away from<br>
> relying on (_S|s)tatic_assert.<br>
<br>
</span>I don't find "someone might rely on this bug" to be compelling. Put<br>
another way, why do we lower the bar for this bug but not others given<br>
that no large projects appear to need this behavior?<br></blockquote><div><br></div><div>Very few people are using clang-cl with C code.  I'm sure it would come up a lot more often if it were better tested.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>><br>
>> Agreed, we have a way forward if we need it. I mostly just want to<br>
>> avoid the burden of supporting that because this is sufficiently weird<br>
>> (being a non-conforming keyword).<br>
><br>
><br>
> It's not conforming, but it's not that weird to define our own keywords. The<br>
> C++ committee chose the keyword "static_assert" because it was unlikely to<br>
> conflict with existing code. MSVC has made this a keyword in C mode and the<br>
> world hasn't burned.<br>
<br>
</span>Correct, we have a way around it, I am just not convinced that we<br>
should put forth the effort of supporting another compiler's bug<br>
without a compelling use-case.<br></blockquote><div><br></div><div>A compelling use case is that users who wish to use static_assert in a conforming C program can do so.</div><div>Today, it is impossible to do this with clang-cl & MSVC's CRT.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span></blockquote></div><br></div></div>