Subject: Re: [EXTERNAL] Macro for <coroutine>
From: Casey Carter (cartec69_at_[hidden])
Date: 2020-01-15 18:14:16
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.
>> 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?
>> SG10 mailing list
SG10 list run by herb.sutter at gmail.com