> On Mar 10, 2016, at 5:10 PM, Nelson, Clark <clark.nelson_at_[hidden]> 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.