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

>