On Thu, Jan 28, 2021 at 9:30 AM Barry Revzin <barry.revzin_at_[hidden]> wrote:

>
>
> On Thu, Jan 28, 2021 at 4:23 AM Jonathan Wakely via SG10 <
> sg10_at_[hidden]> wrote:
>
>>
>>
>> On Thu, 28 Jan 2021 at 10:18, Jonathan Wakely <cxx_at_[hidden]> wrote:
>>
>>>
>>>
>>> On Thu, 28 Jan 2021 at 10:15, Ville Voutilainen <
>>> ville.voutilainen_at_[hidden]> wrote:
>>>
>>>> On Thu, 28 Jan 2021 at 12:13, Jonathan Wakely via SG10
>>>> <sg10_at_[hidden]> wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Wed, 27 Jan 2021 at 20:54, Barry Revzin via Liaison <
>>>> liaison_at_[hidden]> 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
>> SG10_at_[hidden]
>> 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