On Thu, Jan 28, 2021 at 9:30 AM Barry Revzin <[email protected]> wrote:
> > > On Thu, Jan 28, 2021 at 4:23 AM Jonathan Wakely via SG10 < > [email protected]> wrote: > >> >> >> On Thu, 28 Jan 2021 at 10:18, Jonathan Wakely <[email protected]> wrote: >> >>> >>> >>> On Thu, 28 Jan 2021 at 10:15, Ville Voutilainen < >>> [email protected]> wrote: >>> >>>> On Thu, 28 Jan 2021 at 12:13, Jonathan Wakely via SG10 >>>> <[email protected]> wrote: >>>> > >>>> > >>>> > >>>> > On Wed, 27 Jan 2021 at 20:54, Barry Revzin via Liaison < >>>> [email protected]> wrote: >>>> >> >>>> >> Eric Niebler actually asked this on StackOverflow a few years ago: >>>> https://stackoverflow.com/q/48045470/2069064 >>>> >> >>>> >> The accepted answer there is: >>>> >> >>>> >> #define PP_THIRD_ARG(a,b,c,...) c >>>> >> #define VA_OPT_SUPPORTED_I(...) >>>> PP_THIRD_ARG(__VA_OPT__(,),true,false,) >>>> >> #define VA_OPT_SUPPORTED VA_OPT_SUPPORTED_I(?) >>>> > >>>> > >>>> > Who is going to remember that without having to look it up though? >>>> >>>> Is it going to be written so often that that becomes a major problem? >>>> >>>> > The #ifdef __VA_OPT__ solution was my first thought, it's unfortunate >>>> we forbid it. If we can't have that then I think we do need a feature test >>>> macro. The voodoo above will make most developers wish they were using >>>> Rust. >>>> >>>> If they're using VA_OPT, the cause is already lost. >>>> >>> >>> And even if we add a feature test macro now (or allow #ifdef __VA_OPT__) >>> there are still compilers that will reject it with an error (e.g. with >>> -pedantic-errors in pre-C++20 modes). So maybe the ship has sailed and >>> support this feature is already "untestable". You just have to know if your >>> code can use it or not. >>> >> >> Actually that would be true for the #ifdef __VA_OPT__ solution (we could >> say it's allowed, but if you try to use it on today's shipping compilers, >> it's ill-formed) but if we add a new macro you can be conservative: >> >> #ifdef __cpp_va_opt >> // Use it. >> #else >> // Maybe it's actually available, but we can't be sure. >> // Assume it isn't. >> #endif >> >> So the question is whether to spell it __STDC_VA_OPT for WG14 compat, or >> __cpp_va_opt. >> >> -- >> SG10 mailing list >> [email protected] >> https://lists.isocpp.org/mailman/listinfo.cgi/sg10 > > > So from the compilers I have available at my disposal (i.e. on compiler > explorer): > > * gcc trunk, clang trunk, and icc 21.1.9 have __VA_OPT__ in C++20 modes > * gcc even has it in C++17 > * msvc 19.28 doesn't have it yet (that's the latest version up there) > > If you try to use #ifdef __VA_OPT__: > * gcc gives you a warning, but with no label, so you can't disable it. If > you compile with -Werror, you're done. > * clang gives you a warning that you *can* disable > * icc gives an error > * msvc is fine (since it doesn't support it yet, so no special rejection) > > So yeah, #ifdef __VA_OPT__ probably not going to work out as a thing. But > for __cpp_va_opt, is MSVC imminently going to add support for it? It may be > not very informative (true means yes, false means try something else?). > > Barry > I was told to try /Zc:preprocessor for MSVC. In this case, MSVC also supports __VA_OPT__ (and accepts #ifdef __VA_OPT__ without warning or error). But that means all four already support __VA_OPT__, which makes adding a new feature-test-macro kind of questionable to me? Barry
-- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
