On Thu, Jan 16, 2020, 8:29 AM Casey Carter <[email protected]> wrote:
> On Wed, Jan 15, 2020 at 4:20 PM Barry Revzin <[email protected]> > wrote: > >> On Wed, Jan 15, 2020 at 6:14 PM Casey Carter <[email protected]> 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 <[email protected]> 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 >
-- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
