The state of Concepts in Clang

Clang Frontend
1

Hi everyone,

I wanted to ask what the current state of the Concepts TS is in Clang. I
saw some older list threads last year, but also didn't see much in
regard of commits, but maybe I am also looking in the wrong places.

The status page lists it as WIP, but from my own experience I know that
WIP can me anything from "we are running the last tests before release"
to "I have put it on the TODO list".

The background is that we are currently redesigning a large template
library and would really like to make use of concepts. Working with GCC
during development is not a problem, but when we start distributing
first release candidates maybe a year from now, it would be important to
have Clang support, too.

If someone could shed light on the current status and whether there is
an ETA that would help us a lot. Note that I am not implying that anyone
should do anything for us, it's just important for us to know whether
it's something we can likely expect for e.g. clang-6 or "definetely not
in the next two years".

Thank you,
Hannes

2

The Concepts TS implementation for Clang is occurring on trunk; so you are looking in the right place.
Regardless of the implementation status in Clang, the TS remains an experimental design, which may be subject to change.
So, I think that using relying on the Concepts TS in production carries some risks: even if the support is there, it might not be the same as GCC or the current version of the TS.

– HT

3

Hi Hubert,

thanks for the reply and the "warning sign". I am aware that the
discussion on Concepts is ongoing, but there is the published ISO/IEC TS
19217:2015 that GCC implements and it has been rather stable from my
knowledge.
In any case my original question still remains: is there an ETA for
concepts in Clang? Is there a person responsible for it right now that
could have more details?

Thanks,
Hannes

4

Hi Hannes,

At this time, I have been working on Concepts in Clang. I am not sure how “people” are using concepts in GCC, but my experience on unit testing produced a number of internal compiler errors (and I have not found the error messages to be helpful in general). Some cases of those internal compiler errors stem from the cases being underspecified in the TS.

I am not sure an ETA makes sense if the shape of what is going to be delivered is changing. For example, the TS has a one-size-fits-all normalization process which can be overly eager; part of the Clang implementation effort would be to implement (in consultation with the committee) the intended behaviour for each of the uses of normalization.

– HT

5

Hi Hubert,

At this time, I have been working on Concepts in Clang.

Ah, great to know!

I am not sure how
"people" are using concepts in GCC, but my experience on unit testing
produced a number of internal compiler errors

Up until now it has worked ok for me, but I have mostly used rather
basic concepts and only mild "specialization" of concepts.

(and I have not found the error messages to be helpful in general).

True, but that's something where clang had to lead the way before, too,
or not? :slight_smile:

Some cases of those internal
compiler errors stem from the cases being underspecified in the TS.

Haven't had any of those because of concepts, yet.

I am not sure an ETA makes sense if the shape of what is going to be
delivered is changing. For example, the TS has a one-size-fits-all
normalization process which can be overly eager; part of the Clang
implementation effort would be to implement (in consultation with the
committee) the intended behaviour for each of the uses of normalization.

TBH honest I have no real clue of the scope of implementing the TS fully
in Clang (or what the current progress is) so I am not *suggesting*
anything, but maybe if there was a preliminary usable release in Clang
it would get in more testers and help diagnose issues and corner cases?
I thought this was what the committee wanted and why so many things
didn't make it into C++17, i.e. getting people to use TSes early so that
issues can be found and solved before integration into the proper
standard...
Then again, maybe you already know the rough edges well and would rather
figure them out first?

Thanks for the info and of course for working on this,
Hannes

6

Hi Hubert,

> At this time, I have been working on Concepts in Clang.

Ah, great to know!

> I am not sure how
> "people" are using concepts in GCC, but my experience on unit testing
> produced a number of internal compiler errors

Up until now it has worked ok for me, but I have mostly used rather
basic concepts and only mild "specialization" of concepts.

> (and I have not found the error messages to be helpful in general).

True, but that's something where clang had to lead the way before, too,
or not? :slight_smile:

> Some cases of those internal
> compiler errors stem from the cases being underspecified in the TS.
>

Haven't had any of those because of concepts, yet.

> I am not sure an ETA makes sense if the shape of what is going to be
> delivered is changing. For example, the TS has a one-size-fits-all
> normalization process which can be overly eager; part of the Clang
> implementation effort would be to implement (in consultation with the
> committee) the intended behaviour for each of the uses of normalization.

TBH honest I have no real clue of the scope of implementing the TS fully
in Clang (or what the current progress is) so I am not *suggesting*
anything, but maybe if there was a preliminary usable release in Clang
it would get in more testers and help diagnose issues and corner cases?
I thought this was what the committee wanted and why so many things
didn't make it into C++17, i.e. getting people to use TSes early so that
issues can be found and solved before integration into the proper
standard...
Then again, maybe you already know the rough edges well and would rather
figure them out first?

I'm hoping that the roughest of the edges in what the TS is would be
smoothed out before too much effort is spent on things which do not
translate (in terms of reusability or implementation/usage experience) to
later versions.
In some cases, like with concept definitions being also variable or
function templates, extra baggage comes from the existing parts of the
language.

The goal, of course, is to have something available for feedback so that we
know if the decisions made are ones which work for users.
The take away from that though, is that early adopters are, in a sense,
beta testing.

My inclination for writing concepts code (for use, not testing) right now
would be to use function concepts only, limit overloading concept names,
avoid abbreviated function template syntax, and avoid template
introductions.
I would also be very conservative in how I form constraints which are
intended to be "more specific" or "more general" than other constraints.

As for the Clang implementation, we have (at least a sketch of) a plan, but
no idea how difficult it is to execute.
I think there is at least one feature missing from the current TS which is
needed: a way to refer to template parameters which are being specialized
in a specialization.

7

I am not sure an ETA makes sense if the shape of what is going to be
delivered is changing. For example, the TS has a one-size-fits-all
normalization process which can be overly eager; part of the Clang
implementation effort would be to implement (in consultation with the
committee) the intended behaviour for each of the uses of normalization.

TBH honest I have no real clue of the scope of implementing the TS fully
in Clang (or what the current progress is) so I am not *suggesting*
anything, but maybe if there was a preliminary usable release in Clang
it would get in more testers and help diagnose issues and corner cases?
I thought this was what the committee wanted and why so many things
didn't make it into C++17, i.e. getting people to use TSes early so that
issues can be found and solved before integration into the proper
standard...
Then again, maybe you already know the rough edges well and would rather
figure them out first?

I'm hoping that the roughest of the edges in what the TS is would be
smoothed out before too much effort is spent on things which do not
translate (in terms of reusability or implementation/usage experience) to
later versions.
In some cases, like with concept definitions being also variable or
function templates, extra baggage comes from the existing parts of the
language.

The goal, of course, is to have something available for feedback so that we
know if the decisions made are ones which work for users.
The take away from that though, is that early adopters are, in a sense,
beta testing.

Yes, that's ok, I was expecting that.

My inclination for writing concepts code (for use, not testing) right now
would be to use function concepts only, limit overloading concept names,
avoid abbreviated function template syntax, and avoid template
introductions.
I would also be very conservative in how I form constraints which are
intended to be "more specific" or "more general" than other constraints.

Thank you for these suggestions, we will keep them in mind when drafting
a first design for the new library!

As for the Clang implementation, we have (at least a sketch of) a plan, but
no idea how difficult it is to execute.

Ok, cool, let's see. Development happens in trunk, right? So we'll get
it through snapshots. We will start doing CI in early summer and can
report on differences in behviour vs GCC.

I think there is at least one feature missing from the current TS which is
needed: a way to refer to template parameters which are being specialized
in a specialization.

Hm, you mean something like this:

template <typename T1>
concept bool My_int_concept()
{
    return false;
}

template <> // how to explicitly overload for int?
concept bool My_int_concept()
{
    return true;
}

?

Or do you mean specialization as in 2) of
http://en.cppreference.com/w/cpp/language/constraints#Concept_resolution
?

I previously planned designing concepts as variables and don't yet see
the added flexibility of the function interface as really important, but
I agree that it adds consistency to also have function concepts.

Regards,
Hannes

8

>>> I am not sure an ETA makes sense if the shape of what is going to be
>>> delivered is changing. For example, the TS has a one-size-fits-all
>>> normalization process which can be overly eager; part of the Clang
>>> implementation effort would be to implement (in consultation with the
>>> committee) the intended behaviour for each of the uses of
normalization.
>>
>> TBH honest I have no real clue of the scope of implementing the TS fully
>> in Clang (or what the current progress is) so I am not *suggesting*
>> anything, but maybe if there was a preliminary usable release in Clang
>> it would get in more testers and help diagnose issues and corner cases?
>> I thought this was what the committee wanted and why so many things
>> didn't make it into C++17, i.e. getting people to use TSes early so that
>> issues can be found and solved before integration into the proper
>> standard...
>> Then again, maybe you already know the rough edges well and would rather
>> figure them out first?
>>
> I'm hoping that the roughest of the edges in what the TS is would be
> smoothed out before too much effort is spent on things which do not
> translate (in terms of reusability or implementation/usage experience) to
> later versions.
> In some cases, like with concept definitions being also variable or
> function templates, extra baggage comes from the existing parts of the
> language.
>
> The goal, of course, is to have something available for feedback so that
we
> know if the decisions made are ones which work for users.
> The take away from that though, is that early adopters are, in a sense,
> beta testing.

Yes, that's ok, I was expecting that.

> My inclination for writing concepts code (for use, not testing) right now
> would be to use function concepts only, limit overloading concept names,
> avoid abbreviated function template syntax, and avoid template
> introductions.
> I would also be very conservative in how I form constraints which are
> intended to be "more specific" or "more general" than other constraints.

Thank you for these suggestions, we will keep them in mind when drafting
a first design for the new library!

> As for the Clang implementation, we have (at least a sketch of) a plan,
but
> no idea how difficult it is to execute.

Ok, cool, let's see. Development happens in trunk, right? So we'll get
it through snapshots. We will start doing CI in early summer and can
report on differences in behviour vs GCC.

Development does happen on trunk. I am not entirely sure that the
implementation would be ready to consume a concept-enabled library at that
time.

> I think there is at least one feature missing from the current TS which
is
> needed: a way to refer to template parameters which are being specialized
> in a specialization.
>

Hm, you mean something like this:

template <typename T1>
concept bool My_int_concept()
{
    return false;
}

template <> // how to explicitly overload for int?
concept bool My_int_concept()
{
    return true;
}

?

Or do you mean specialization as in 2) of
Constraints and concepts (since C++20) - cppreference.com
?

Neither.

Given:
template <typename T>
struct A {
  void foo() requires OkayA<T> || T::okay;
  void foo() requires OkayB<T>;
};

How would you explicitly specialize the first A<int>::foo?

template <>
void A<int>::foo() requires OkayA<int> || int::okay // seems wrong
{ }

I previously planned designing concepts as variables and don't yet see
the added flexibility of the function interface as really important, but
I agree that it adds consistency to also have function concepts.

I am not sure that concept definitions should be variable or functions at
all.
My interpretation of the function concepts is that they are a shortcut in
the specification to allow for overloading of concept names.

9

I'll note that the Ranges proposal [1] exclusively specifies function
concepts.

Tom.

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4620.pdf

10

> I previously planned designing concepts as variables and don't yet see
> the added flexibility of the function interface as really important, but
> I agree that it adds consistency to also have function concepts.

I'll note that the Ranges proposal [1] exclusively specifies function
concepts.

Which makes sense if you believe in overloading concept names.

There's a proposal (not yet reviewed by the committee) on (characterization
mine) being more conservative about how Concepts are in C++:

-- HT

11

As well as the following ones that also have not yet been reviewed:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0324r0.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0464r1.html

Tom.