I think we should follow the convention of having both cpp_impl and cpp_lib macros for coroutines. Users should use the new cpp_lib one.

We could keep the old macro around or get rid of it with the rationale that it is providing information about the wrong thing (the implementation and not the library).

John .

> On Jan 15, 2020, at 11:04 PM, Barry Revzin via SG10 <sg10_at_[hidden]> wrote:
>
> 
>
>
>> On Thu, Jan 16, 2020, 8:29 AM Casey Carter <cartec69_at_[hidden]> wrote:
>>> On Wed, Jan 15, 2020 at 4:20 PM Barry Revzin <barry.revzin_at_[hidden]> wrote:
>>
>>>> On Wed, Jan 15, 2020 at 6:14 PM Casey Carter <cartec69_at_[hidden]> wrote:
>>>
>>>> I suppose I'm saying "it would be nice to have these two distinct feature-test macros, but it may be too late now since __cpp_coroutines has an established history."
>>>>
>>>>> On Wed, Jan 15, 2020 at 4:13 PM Casey Carter <cartec69_at_[hidden]> wrote:
>>>>
>>>>> As a rule, it's useful to have distinct macros to indicate compiler and library support of a feature that has both core language and library surface. Standard libraries can then provide the library support / define the library macro only when the necessary compiler support is present. If the feature is unusable without library support, e.g., coroutines, users check only the library macro.
>>>>>
>>>
>>> How established? Just #include <coroutine> fails on latest gcc, clang w/libc++, and the latest msvc on godbolt - unless there are extra flags I need to pass in to get this to work on any of them: https://godbolt.org/z/oy9hzc
>>
>> __cpp_coroutines has indicated support for TS coroutines for years (https://godbolt.org/z/f_97UG).
>
>
> Notably though, you need -stdlib=libc++ on clang to include the coroutine header.
>
> Which kind of suggests the need for the library macro, since how would you write something that works with clang + libstdc++ otherwise?
>
> Barry
> --
> SG10 mailing list
> SG10_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg10