> 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.

Technically, supporting constexpr as in C++14 requires support for
simulating the execution of arbitrary statements, and that's hard.
But support for a constexpr lambda containing just a return or
expression statement could be implemented without all that. The
question is, how likely is it that someone would do things in
that order?

> 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 not sure I'm comfortable with that as a blanket principle.
Let's keep it in mind, but I don't want to take it as given --
at least not yet.

> 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”.

That principle is stated in this week's update to SD-6:

" Therefore, if the most useful purpose for a feature-test macro
would be to control the inclusion of a #error directive if the feature
is unavailable, that is considered inadequate justification for the
macro. "

> 2. Constexpr lambdas is more of a constexpr feature than a lambda
> one.

I would agree with that.

> 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.

You have a point. OTOH, at some point someone (hopefully) had an
implementation of generic lambdas (before the committee added it to
the WD), and may not already have had an implementation of init
capture. Such a person might want to enable the feature they have
already implemented before going on to implement a new feature
(proposed by someone else, perhaps).

> What do folks think?

Does anyone feel that the availability of constexpr lambda would be
better indicated through __cpp_lambdas than through __cpp_constexpr?
I'm hoping we can drop __cpp_lambdas from consideration.

I think it would be perfectly reasonable to bump __cpp_constexpr again
for lambdas. But I'm still leaning towards having a separate macro for
capturing *this, at least in part for consistency with
__cpp_init_capture.

Clark