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.
>
> 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
>>
>