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.

On Tue, Jan 14, 2020 at 5:45 PM Barry Revzin via SG10 <sg10_at_[hidden]>
wrote:

> I'm not sure, just thought I'd ask.
>
> Barry
>
> On Wed, Jan 15, 2020, 1:28 AM Gor Nishanov <gorn_at_[hidden]> wrote:
>
>> Correct. You cannot define coroutine types, like a task or generator
>> without including <coroutine> header.
>>
>> What would be the purpose of the __cpp_lib_coroutines?
>> How do you envision it is going to be used?
>> ------------------------------
>> *From:* Barry Revzin <barry.revzin_at_[hidden]>
>> *Sent:* Monday, January 13, 2020 9:07 PM
>> *To:* sg10_at_[hidden] <sg10_at_[hidden]>
>> *Cc:* lbaker_at_[hidden] <lbaker_at_[hidden]>; Gor Nishanov <gorn_at_[hidden]>
>> *Subject:* [EXTERNAL] Macro for <coroutine>
>>
>> Hi SG10,
>>
>> We currently have the feature test macro __cpp_coroutines, but we have no
>> macro for the library machinery in <coroutine>. I'm not super familiar with
>> coroutines, but it seems like this works a lot like <=> and <compare> where
>> you need the library bit to do anything?
>>
>> Should we then change the language macro to __cpp_impl_coroutines and
>> introduce a new library macro __cpp_lib_coroutines, that users check for?
>>
>> Barry
>>
> --
> SG10 mailing list
> SG10_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg10
>