> On Mar 10, 2016, at 5:10 PM, Nelson, Clark <[email protected]> wrote: > >> On 03/10/2016 01:41 PM, John Spicer wrote: >>> I’m wondering whether some of these should be updated values of >> existing macros. >>> >>> For example, capture of this and constexpr lambdas *could* be an >> update of __cpp_lambdas. >> >> Agreed, sounds more reasonable to me. > > I can see how the ability to add "constexpr" to a lambda might be > considered just a tweak. But, for example, we already have > __cpp_generic_lambdas. > > A new kind of capture seems to me to be a different sort of thing. > And, for example, we already have __cpp_init_captures. >
I guess the question gets back to the issue that Jason alluded to. To what extent, if any, does support for a later feature imply support for an earlier one. Although there is no guarantee that this will be the case, I think we could assume that all C++14 features will be implemented when people are trying to detect C++17 features. I’m trying to find the balance between too many macros and not enough macros. Somewhere the guideline that you must have a reasonable way to write the code with or without the feature for the macro to be helpful. Although I don’t recall where we came down on the question about using a macro just as a static_assert to say “you can’t compile this code with this compiler”. I think my current feeling is: 1. It is good to have fewer macros in cases where that makes sense. 2. Constexpr lambdas is more of a constexpr feature than a lambda one. 3. We might want to choose values in a way that we think indicates a likely ordering and not simply on the date of the paper. For example. init captures has the same date as generic lambdas, but I think it is unlikely for someone to implement generic lambdas without init captures. On the other hand, I can see the argument that a larger number of simple macros is better than a smaller number of more complex ones. So…. What do folks think? John. _______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
