On Thu, Mar 24, 2016 at 11:49 AM, Reid Kleckner <r...@google.com> wrote: > On Thu, Mar 3, 2016 at 10:40 AM, Aaron Ballman <aa...@aaronballman.com> > wrote: >> >> That was what I meant by "justification". I would say it has to be >> reasonably compelling code (win32 headers, boost, some other major >> library) as that's our usual bar for these sort of bug-for-bug >> compatible things, as I understand it. > > > I'd rather apply this patch now than wait for ffmpeg or someone to try to > use static_assert and then have to hustle to get this into clang. Many many > C projects have COMPILE_ASSERT macros that are just a small change away from > relying on (_S|s)tatic_assert.
I don't find "someone might rely on this bug" to be compelling. Put another way, why do we lower the bar for this bug but not others given that no large projects appear to need this behavior? >> >> Agreed, we have a way forward if we need it. I mostly just want to >> avoid the burden of supporting that because this is sufficiently weird >> (being a non-conforming keyword). > > > It's not conforming, but it's not that weird to define our own keywords. The > C++ committee chose the keyword "static_assert" because it was unlikely to > conflict with existing code. MSVC has made this a keyword in C mode and the > world hasn't burned. Correct, we have a way around it, I am just not convinced that we should put forth the effort of supporting another compiler's bug without a compelling use-case. ~Aaron _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
