Using Concepts Lite

[Andrzej Krzemieński]

Hi Everyone,
I would like to ask the experts and the authors of Concepts Lite how I should use the feature in my particular use case. I want to say in my constraints that a given class has to have a nested type and two static member functions working on the type. For instance, the following type satisfies my requirements:

struct Coder
{
    using encoded_representation = std::string;
    static encoded_representation encode(std::string s) { return s; }
    static std::string decode(encoded_representation r) { return r; }
};

I came out with the following concept:

template <typename C>
concept bool Decoder = requires(typename C::encoded_representation r, std::string s)
{
    typename C::encoded_representation;
    { C::encode(s) } -> typename C::encoded_representation;
    { C::decode(r) } -> std::string;
};

And it seams to work (see here) in GCC; but I am not sure if this is per requirements, or if GCC is too generous. What I feel uneasy about that before I specify that encoded_representation represents a nested type I am already using it in argument list of requires expression. I would imagine that concept declaration would be illegal, but GCC seams to treat it as an implied atomic constraint. Is it per specification? If so, can you point me to the right place in TS?

A similar question arises in the following concept definition:

template <typename T>
concept bool C = requires(T v)
{
    requires pred(v);
};

I specify that a given compile-time predicate must be true, but I do not specify that expression pred(v) must be well formed and convertible to bool. But GCC accepts it and treats the latter as an implied atomic constraint. (See here.) Is it just GCC, or does the TS require it? And if so, where is it expressed in the TS?

Thanks,
&rzej

[Andrew Sutton]

> template <typename C>
> concept bool Decoder = requires(typename C::encoded_representation r,
> std::string s)
> {
> typename C::encoded_representation;
> { C::encode(s) } -> typename C::encoded_representation;
> { C::decode(r) } -> std::string;
> };
>
> And it seams to work (see here) in GCC; but I am not sure if this is per
> requirements, or if GCC is too generous. What I feel uneasy about that
> before I specify that encoded_representation represents a nested type I am
> already using it in argument list of requires expression. I would imagine
> that concept declaration would be illegal, but GCC seams to treat it as an
> implied atomic constraint. Is it per specification? If so, can you point me
> to the right place in TS?

It's not an implied atomic constraint, but part of a parameterized
constraint. r is a constraint variable. If substitution through the
constraint variables of parameterized constraint fails, the constraint
is not satisfied.

But if you really don't like writing the use before the requirement,
you can split the requirements:

concept bool Decoder =
requires { typename C::encoded_representation; } &&

requires(typename C::encoded_representation r, std::string s) {
typename C::encoded_representation;
{ C::encode(s) } -> typename C::encoded_representation;
{ C::decode(r) } -> std::string;
};

> A similar question arises in the following concept definition:
>
> template <typename T>
> concept bool C = requires(T v)
> {
> requires pred(v);
> };
>
> I specify that a given compile-time predicate must be true, but I do not
> specify that expression pred(v) must be well formed and convertible to bool.
> But GCC accepts it and treats the latter as an implied atomic constraint.
> (See here.) Is it just GCC, or does the TS require it? And if so, where is
> it expressed in the TS?

Same rule, if substitution into the constraint expression fails, the
constraint is not satisfied.

In general there is no rule that a type or expression constraint
appear before the use of that type or or expression. However, this
style will prevent the compiler for generating the best diagnostics
that it can.

Andrew

[Andrzej Krzemieński]

Thanks a lot. And this notation with conjunction is really clever.

Regards,
&rzej