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@lists.isocpp.org> wrote:
I'm not sure, just thought I'd ask.

Barry

On Wed, Jan 15, 2020, 1:28 AM Gor Nishanov <gorn@microsoft.com> 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@gmail.com>
Sent: Monday, January 13, 2020 9:07 PM
To: sg10@lists.isocpp.org <sg10@lists.isocpp.org>
Cc: lbaker@fb.com <lbaker@fb.com>; Gor Nishanov <gorn@microsoft.com>
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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg10