> 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 _______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
