Re: [SG10] Changes for C++11 and 98

On 8 October 2014 20:03, Ed Smith-Rowland wrote: This looks great. I think we're out of stubs. ;-) If we're feeling bad about that This came out of the 2014-05 fundamentals-ts paper. I'm sure there will be more input like this after the meeting. These can wait though: They've appeared

[SG10] Should the argument to __has_cpp_attribute be expanded by the preprocessor?

We couldn't wok out whether SD-6 intends this to work: #define D deprecated #if __has_cpp_attribute (D) #endif Currently GCC performs macro-expansion but Clang doesn't. ___ Features mailing list Features@isocpp.open-std.org

Re: [SG10] Last-minute changes

On 10 April 2015 at 01:13, Nelson, Clark wrote: The most important change is that I have added examples for some library features. Now, the fact that I have dared even to attempt to write examples for C++ library features should give anyone who knows me only moderately well some idea of how

Re: [SG10] Changes to any/optional

On 22 July 2016 at 01:48, Richard Smith wrote: > On Thu, Jul 21, 2016 at 4:59 PM, Nelson, Clark > wrote: > >> > All the variant changes from Oulu should be covered by >> > __has_include(); I don't think we have a need to track them >> > separately

Re: [SG10] Updated SD-6 draft

On 3 August 2016 at 18:33, Jonathan Wakely wrote: > > > > I've also noticed that for my paper P0074R0, the existing macro > __cpp_lib_transparent_operators was changed, rather than adding a new one.The > P0074R0 changes only affect (specifically, the shared_ptr helper

Re: [SG10] Updated SD-6 draft

On 3 August 2016 at 18:17, Nelson, Clark wrote: > > The row for __cpp_lib_not_fn says the header is which > > should be > > Thanks. > > > The row for __cpp_lib_lock_guard_variadic says the header is > > but lock_guard is defined in > > OK, thanks again. As it turns

Re: [SG10] Updated SD-6 draft

Example for P0083R3 __cpp_lib_node_extract: void update(std::set& set, const X& elem, int val) { auto pos = set.find(elem); if (pos == set.end()) return; #if __cpp_lib_node_extract auto next = std::next(pos); auto x = set.extract(pos); x.value().update(val); set.insert(next,

[SG10] Checking __has_include on its own is not sufficient

It's become apparent that the feature-test recommendations for features such as std::string_view, std::variant and std::optional are not sufficient. SD-6 says that to check for std::variant you should use __has_include(). This doesn't always work, for example: #ifdef __has_include #if

Re: [SG10] Checking __has_include on its own is not sufficient

On 9 February 2017 at 23:25, Jens Maurer <jens.mau...@gmx.net> wrote: > On 02/09/2017 11:59 PM, Jonathan Wakely wrote: >> It's become apparent that the feature-test recommendations for >> features such as std::string_view, std::variant and std::optional are >> not

Re: [SG10] SD-6 document structure

The zero-width spaces were a minor inconvenience when I was copying & pasting macro names out of the table into source code ... not a big inconvenience though (my editor showed them as some non-printable character so I saw them right away). I think splitting the tables from the examples and

[SG10] __has_cpp_attribute example

The SD-6 draft has [3.3.6] Example This demonstrates a way to use the attribute [[deprecated]] only if it is available. #ifdef __has_cpp_attribute # if __has_cpp_attribute(deprecated) #define ATTR_DEPRECATED(msg) [[deprecated(msg)]] # else #define ATTR_DEPRECATED(msg) # endif #endif

Re: [SG10] __has_cpp_attribute example

On 12 October 2016 at 12:51, Aaron Ballman <aa...@aaronballman.com> wrote: > On Wed, Oct 12, 2016 at 6:55 AM, Jonathan Wakely <c...@kayari.org> wrote: >> The SD-6 draft has >> >> [3.3.6] Example >> >> This demonstrates a way to use the attrib

Re: [SG10] Adding a macro to identify the ABI

On 8 January 2017 at 19:30, Saleem Abdulrasool wrote: > std::type_info comes from the runtime. Someone needs to implement it for > our to be provided. Agreed so far. > Having the compiler identify the ABI means that the runtime has a concrete > manner to determine what ABI is being requested.

[SG10] Macro for P0084R2: Emplace Return Type

Do we need a macro for this? I can't think of a sensible example where it would help. #if __cpp_lib_emplace_return_type auto& x = container.emplace_back(arg1, arg2); #else container.emplace_back(arg1, arg2); auto& x = container.back(); #endif If you want to work with compilers that don't

[SG10] Bump value of __cpp_lib_chrono for P0505R0?

The macro is currently set to 201510 following P0092R1. In Kona P0505R0 added constexpr in a few more places, which are only very minor changes. I don't think we need a new macro, so setting the value to 201703 seems appropriate. Hmm, although this assumes nobody would implement the latter

Re: [SG10] A feature macro for mandatory copy elision

On 9 October 2017 at 17:10, Nelson, Clark wrote: > Perhaps I should also ask: should the name of the macro use the word > "mandatory", or would "guaranteed" (as from the original document title) be > better? > > Yes, I was going to suggest "guaranteed". > Clark > > >

Re: [SG10] P0032R3: Homogeneous interface for variant, any and optional

On 7 September 2017 at 18:09, Nelson, Clark wrote: > I noticed that, although our draft says that there should be no macro for > P0032R3, we have no statement of rationale for that absence. So I looked into > the situation a little closer, to see if I could figure out

[SG10] List of headers for _cpp_lib_incomplete_container_elements

The headers that should define the macro are , and ___ Features mailing list Features@isocpp.open-std.org http://www.open-std.org/mailman/listinfo/features

Re: [SG10] Filesystem questions

On 7 September 2017 at 01:23, Nelson, Clark wrote: > So it looks like the only remaining questions in the C++17 table that we > haven't considered yet are what to do about new features in the filesystem > library. > > Unless someone on this list comes up with a suggestion, I'll reach out to >

Re: [SG10] A feature macro for mandatory copy elision

On 6 October 2017 at 01:19, Herb Sutter wrote: > > why you would not use that alternative in all cases if you want your > code to be portable across compilers > > > > Because he wants to use the new better features on those compilers that > support them. > > > > This is

Re: [SG10] __cpp_lib_tuple_element_t should be defined in not

shouldn't need to #include . P0941R2 will be on the Straw Polls page tomorrow in Rapperswil - thanks to Clark for the initial version of the paper that made this happen (and of course for all the work on SD-6!) On 8 June 2018 at 10:39, Jonathan Wakely wrote: > The Albuquerque draft of SD-6 gi

[SG10] __cpp_lib_tuple_element_t should be defined in not

The Albuquerque draft of SD-6 gives the header for __cpp_lib_tuple_element_t as but it's defined in (in all of the http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3887.pdf proposal that defined it, C++14, C++17, and the latest WP). ___

Re: [SG10] no feature test macro for destroying delete

On 14 June 2018 at 14:08, John Spicer wrote: > > > On Jun 13, 2018, at 9:12 PM, Richard Smith > wrote: > > > > P0722R3 (wg21.link/p0722r3, just voted into the standard) does not > specify a feature test macro, but I think it would benefit from one. > However, it's not completely clear how we

Re: [SG10] no feature test macro for destroying delete

On 14 June 2018 at 14:31, John Spicer wrote: > > On Jun 14, 2018, at 9:22 AM, Jonathan Wakely wrote: > > > > On 14 June 2018 at 14:08, John Spicer wrote: > >> >> > On Jun 13, 2018, at 9:12 PM, Richard Smith >> wrote: >> > >> > P0

Re: [SG10] no feature test macro for destroying delete

On 14 June 2018 at 14:59, John Spicer wrote: > > On Jun 14, 2018, at 9:38 AM, Jonathan Wakely wrote: > > > > On 14 June 2018 at 14:31, John Spicer wrote: > >> >> On Jun 14, 2018, at 9:22 AM, Jonathan Wakely wrote: >> >> >> >> On 14 Ju

[SG10] Is __cpp_lib_constexpr_char_traits "official"?

I don't see it in P0096R5, although http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0426r1.html recommended it. It seems to be useful to know whether you can use char_traits::length() in a constexpr function, or whether you need to write your own.

[SG10] Example for __cpp_lib_byte

Would something like this be suitable? #if __cpp_lib_byte >= 201603 using byte_type = std::byte; #else using byte_type = unsigned char; #endif alignas(T) byte_type rawbytes[sizeof(T)]; // ... Both forms will work, but the std::byte version might be preferred to ensure that no arithmetic

[SG10] SD-6 gives wrong header for __cpp_lib_to_chars

SD-6 says the __cpp_lib_to_chars macro is defined in , because that's where P0067R5 added std::to_chars and std::from_chars. However, not long after they were moved to their own header, . The feature test macro should be defined in there, not · No implementation shipped with them in so there's

Re: [SG10] New feature test macros

On Fri, 9 Nov 2018 at 19:43, Hubert Tong wrote: > Would it be wrong to replace "impl" with "core"? > Either core or impl in there seems OK to me. > > -- HT > > On Fri, Nov 9, 2018 at 11:39 AM John Spicer wrote: > >> On Tuesday we discussed a few feature test macros that we want added at >>

[SG10] Macro for P0458

A colleague queried the absence of a feature-test macro for https://wg21.link/p0458 "Checking for Existence of an Element in Associative Containers". I couldn't find any record of discussion in LWG review or on this mailing list to indicate whether the omission was intentional or an oversight.

[SG10] New issue: and should define __cpp_lib_parallel_algorithm

There are parallel overloads of algorithms in , so it should define the macro. Also, defines the exec policies for use with the algos, so that should define the macro too. Proposed resolution: In [support.limits.general] add and to the table row for __cpp_lib_parallel_algorithm. |

Re: [SG10] New issue: and should define __cpp_lib_parallel_algorithm

Looks good, thanks. On Thu, 13 Jun 2019 at 22:07, Daniel Krügler wrote: > Am Mi., 12. Juni 2019 um 21:58 Uhr schrieb Jonathan Wakely >: > > > > There are parallel overloads of algorithms in , so it should > define the macro. Also, defines the exec policies for use

Re: [SG10] nodiscard updates after Cologne?

On Fri, 30 Aug 2019 at 00:56, Aaron Ballman wrote: > On Thu, Aug 29, 2019 at 7:49 PM Barry Revzin > wrote: > > > > We had two changes to [[nodiscard]] in Cologne: > > > > - P1301R4: [[nodiscard("should have a reason")]], for C++20 > > - P1771R1: [[nodiscard]] for constructors, as a DR > > > >

Re: [SG10] Missing feature-test macros since 2017

On Fri, 30 Aug 2019 at 02:18, Ben Craig wrote: > Is there consensus that bumping the value is the right design for feature > additions? I see value bumping as valuable when a design changes (e.g. the > many iterations of move semantics, the changing rules around spaceship), > but when there is

[SG10] New issue: missing feature test macro for

There is no feature test macro for std::span. For the purposes of SD-6, I think we want two values: 201803L for the original addition of by P0122R7 (Jacksonville, 2018) and then 201902L for the API changes from P1024R3 (Kona, 2019). The C++ working draft only needs the newer value. Proposed

Re: [SG10] Missing feature-test macros since 2017

On Thu, 29 Aug 2019 at 04:05, Barry Revzin wrote: > Hey all, > > I updated the SD-6 document on isocpp.org: https://wg21.link/sd6. I'm > still having some CSS woes, but otherwise I updated the original document > with the feature-test macros that have been adopted since it was first > written,

Re: [SG10] New issue: missing feature test macro for

On Sat, 14 Sep 2019, 17:25 Daniel Krügler, wrote: > Am Do., 5. Sept. 2019 um 13:51 Uhr schrieb Jonathan Wakely >: > > > > There is no feature test macro for std::span. > > > > For the purposes of SD-6, I think we want two values: 201803L for the > original addi