I believe these are meaningful as base values assuming an implementation is far enough along to set __cpp_concepts, covering `concept` versus `concept bool` and the atomic constraint matching through location + parameter mapping.

__cpp_concepts: 201507 (TS) or 201707 (P0734).
__cpp_requires_expr: 201507 (TS) or 201611 (P0266).
__cpp_compound_req: 201507 (TS) or 201707 (P0734) or 201811 (P1084). Only 201507 allows placeholder types.
__cpp_concept_placeholders: 201507 (TS) or 201811 (P1141).

On Fri, Mar 1, 2019 at 4:26 PM John Spicer <jhs@edg.com> wrote:
[ Dropping core reflector ]

Do you have a recommendation?

John.

On Mar 1, 2019, at 12:03 PM, Hubert Tong <hubert.reinterpretcast@gmail.com> wrote:

I'm still hoping for some SG10 guidance on whether we want to query on what -> Concept does separately from whether Concept auto is available. There is also static_assert(C<T>) in the mix somewhere.

-- HT

On Fri, Mar 1, 2019 at 8:45 AM John Spicer <jhs@edg.com> wrote:
That seems appropriate to me (copying the core reflector).

John.

> On Mar 1, 2019, at 7:21 AM, Jonathan Wakely <cxx@kayari.org> wrote:
>
> The working draft doesn't specify a __cpp_concepts macro. I want to know if I need to say "concept bool" or just "concept", so I expected to be able to do:
>
> #if __cpp_concepts
> template<typename T>
>   concept
> #if __cpp_concepts <= 201507
>   bool
> #endif
>   Foo = ...;
> #endif
>
> Should this be handled by a core issue?
>
> _______________________________________________
> Features mailing list
> Features@isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/features

_______________________________________________
Features mailing list
Features@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/features