Date: Thu, 16 Jan 2020 15:07:22 +0000
I think that, at a minimum, we should add a cpp_lib macro for coroutines. I do not feel strongly one way or the other about what to do with the existing macro.
From: SG10 <sg10-bounces_at_[hidden]> On Behalf Of John Spicer via SG10
Sent: Thursday, January 16, 2020 8:32 AM
To: sg10_at_[hidden]
Cc: John Spicer <jhs_at_[hidden]>; Gor Nishanov <gorn_at_[hidden]>
Subject: Re: [SG10] [EXTERNAL] Macro for <coroutine>
I think we should follow the convention of having both cpp_impl and cpp_lib macros for coroutines. Users should use the new cpp_lib one.
We could keep the old macro around or get rid of it with the rationale that it is providing information about the wrong thing (the implementation and not the library).
John .
On Jan 15, 2020, at 11:04 PM, Barry Revzin via SG10 <sg10_at_[hidden]<mailto:sg10_at_[hidden]>> wrote:
On Thu, Jan 16, 2020, 8:29 AM Casey Carter <cartec69_at_[hidden]<mailto:cartec69_at_[hidden]>> wrote:
On Wed, Jan 15, 2020 at 4:20 PM Barry Revzin <barry.revzin_at_[hidden]<mailto:barry.revzin_at_[hidden]>> wrote:
On Wed, Jan 15, 2020 at 6:14 PM Casey Carter <cartec69_at_[hidden]<mailto:cartec69_at_[hidden]>> 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 <cartec69_at_[hidden]<mailto: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.
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<https://urldefense.com/v3/__https:/godbolt.org/z/oy9hzc__;!!FbZ0ZwI3Qg!6x6yfTWDuAbmHxvl3wpooEZylhdGuBOB3dM9x13KftHPFpSoQ-RKPhRVoUVY$>
__cpp_coroutines has indicated support for TS coroutines for years (https://godbolt.org/z/f_97UG<https://urldefense.com/v3/__https:/godbolt.org/z/f_97UG__;!!FbZ0ZwI3Qg!6x6yfTWDuAbmHxvl3wpooEZylhdGuBOB3dM9x13KftHPFpSoQ-RKPr0wcUu1$>).
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
SG10_at_[hidden]<mailto:SG10_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg10<https://urldefense.com/v3/__https:/lists.isocpp.org/mailman/listinfo.cgi/sg10__;!!FbZ0ZwI3Qg!6x6yfTWDuAbmHxvl3wpooEZylhdGuBOB3dM9x13KftHPFpSoQ-RKPm95EeIO$>
From: SG10 <sg10-bounces_at_[hidden]> On Behalf Of John Spicer via SG10
Sent: Thursday, January 16, 2020 8:32 AM
To: sg10_at_[hidden]
Cc: John Spicer <jhs_at_[hidden]>; Gor Nishanov <gorn_at_[hidden]>
Subject: Re: [SG10] [EXTERNAL] Macro for <coroutine>
I think we should follow the convention of having both cpp_impl and cpp_lib macros for coroutines. Users should use the new cpp_lib one.
We could keep the old macro around or get rid of it with the rationale that it is providing information about the wrong thing (the implementation and not the library).
John .
On Jan 15, 2020, at 11:04 PM, Barry Revzin via SG10 <sg10_at_[hidden]<mailto:sg10_at_[hidden]>> wrote:
On Thu, Jan 16, 2020, 8:29 AM Casey Carter <cartec69_at_[hidden]<mailto:cartec69_at_[hidden]>> wrote:
On Wed, Jan 15, 2020 at 4:20 PM Barry Revzin <barry.revzin_at_[hidden]<mailto:barry.revzin_at_[hidden]>> wrote:
On Wed, Jan 15, 2020 at 6:14 PM Casey Carter <cartec69_at_[hidden]<mailto:cartec69_at_[hidden]>> 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 <cartec69_at_[hidden]<mailto: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.
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<https://urldefense.com/v3/__https:/godbolt.org/z/oy9hzc__;!!FbZ0ZwI3Qg!6x6yfTWDuAbmHxvl3wpooEZylhdGuBOB3dM9x13KftHPFpSoQ-RKPhRVoUVY$>
__cpp_coroutines has indicated support for TS coroutines for years (https://godbolt.org/z/f_97UG<https://urldefense.com/v3/__https:/godbolt.org/z/f_97UG__;!!FbZ0ZwI3Qg!6x6yfTWDuAbmHxvl3wpooEZylhdGuBOB3dM9x13KftHPFpSoQ-RKPr0wcUu1$>).
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
SG10_at_[hidden]<mailto:SG10_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg10<https://urldefense.com/v3/__https:/lists.isocpp.org/mailman/listinfo.cgi/sg10__;!!FbZ0ZwI3Qg!6x6yfTWDuAbmHxvl3wpooEZylhdGuBOB3dM9x13KftHPFpSoQ-RKPm95EeIO$>
Received on 2020-01-16 09:09:58