[SUGGESTION] C++0x concepts for cpp2

[AbhinavK00]

Concepts in cpp20 have made generic programming easier but they still leave a lot to be desired, after all they are called concepts "lite" for a reason. P1900 describes some desired features from concepts. Along with those features, concepts are only that much useful as much as they used. Currently there is no mechanism to force the use of concepts too (which P1900 does not mention).
While this is not a full suggestion, it is more of a question if Herb would like a mechanism similar to C++0x concepts to be present in cpp2?
A lot of work was done on that feature, and it almost made it into the language except that it didn't (I don't know the reasons but Herb, as being someone from the commitee would probably know).

Alternatives considered : Interfaces in cpp2 could somehow emulate both nominal concepts and customisation points but features like associated types, type erasure are still left desired.

[AbhinavK00]

I was hoping to get some feedback to this issue. If Herb doesn't want that in cpp2, he can close but I'd like to see what his views are.

[JohelEGP]

See https://youtu.be/CXn02MPkn8Y?t=176.
Apparently, C++0x concepts

were kind of complicated and no one understood them.

[AbhinavK00]

First of all, THANKS for a reply.
Second of all, they were not complicated but hard to use in the final form that was agreed upon (which Bjarne didn't like and it ultimately led to their cancellation). While most of those features would probably require something at language level, one feature that I think is essential is early definition checking of template functions.
N1848 section 4 describes how that would work. Even this one I'm not sure if it can be implemented.

There's also notion of nominal concepts which are explicitly opt in. They can be easily emulated with interfaces (on cpp2 side) and std::derived_from (on cpp side) so that's one more thing.

[hsutter]

Good question!

It wasn't really so much that Bjarne didn't like C++0x concepts... Bjarne wanted C++0x concepts to succeed, despite their flaws and despite that they were a compromise design between his group and another group, and he was not happy that they didn't make it into C++11.

The issues were that:

• There were unresolved design questions, such as how to apply them to the standard library. At the time people were proposing over 100 concepts, and part of that was because of the C++0x concepts design, IIRC.
• There were unresolved implementation and performance questions. At the time, the prototype implementation was not efficient enough to be used in production, and some believed it could be improved but nobody was able to do the work to demonstrate that C++0x concepts could be implemented efficiently enough to be deployed in a real-world project. AIUI, a lot of this came from that C++0x concepts assumed the existence of a "concept map" intermediate layer with the hope that it would be possible to optimize away the overhead of that layer, but while C++ has occasionally had success with the "add overheads and then try to optimize them away" approach, most of the time that strategy has not succeeded in C++ and this is one example of where it didn't succeed (it has succeeded well in managed languages, which are okay with not being as fast as C++).

Also, a (the?) major operational difference between C++0x concepts and C++20 concepts is definition checking. Definition checking is definitely [sic] valuable, but remember the rule: There are way more readers than writers, way more users and authors, way more call sites than definitions. In this case, that means checking call sites delivers well over 99% of the mistake-diagnosing value of concepts (for popular concepts like those in std::, it's more like 99.99999% because there will be many millions of uses of a given single popular concept). So while the argument for definition checking is sound, and it would be fine to get it if we could, the reality is that its value is by far dominated by call-site checking. So I agree with the decision to move forward with concepts to get call-site checking, and not let attempts to also get definition checking continue slowing down achieving that benefit.

[AbhinavK00]

In this case, that means checking call sites delivers well over 99% of the mistake-diagnosing value of concepts

I disagree here. Absence of definition checking leads to problems. The easy one to think about is that a programmer can forget to put all the constraints on their function which leads us back to "before concept" era. It may continue to work for a long time until someone passes a paramater that violates that one specific missed contraint and everything falls apart. But the bigger problems that I think is that no defintion checking means that concepts do not propagate up.
If I have a function with contraints A and B and I call it in another function, there's nothing forcing me to write my new function with those constraint or a superset, I may write my new function with no constraint at all and it may continue to work for quite long time. Now imagine the same function but buried under hundreds of others, you error message would be long like current ones. This may become an issue if you don't have access to the defintion of functions.

Edit: I really wanted to give a code example but couldn't get one.

With defintion checking, concept propagation automatically happens and therefore all the errors you get are on the top level function. That's why I'd say that its defintion checking that delivers 99% of the mistake-diagnosing value of concepts. Without it, you have to hope that programmers won't make mistakes which we all know how it plays out.

If there's one feature that I hope is implemented from this discussion, it would be defintion checking.

Another discussion that I would want to get started is about structural vs nominal concepts. Structural concepts were right for cpp because there was so much code out there, but cpp2 doesn't have that problem so nominal concepts could be considered. Even I'm divided on this issue so idk.
This article describes how we could emulate nominal concepts, so we have a way but do want them? I'd like to hear others' opinions on that.
As for other features, maybe we can delay discussion on those because cpp itself would probably get them sooner or later.

[AbhinavK00]

As mentioned above, most (not all) of true definition checking can be covered by unit testing, such as by writing the archetypes that Andrzej shows.

Two points:

most (not all) of true definition checking can be covered by unit testing

Most is not good enough IMHO, plus a compiler would do a great job at definition checking since it has the all the information there is to have.

such as by writing the archetypes

Yes, but then its a job deferred to the programmer which not all people do (its like a not-RAII-managed resource), having the langauge enforce it would be nice.

We use unit tests to check our library functions'/types' (interfaces and) definitions for static and dynamic behavior that's beyond what the language and type system guarantee

This is something I 100% agree with, if the language can't do it, then unit tests to the rescue. Here, we have a language at hand, so there's no problem of getting the feature through a committee. Then there's the argument of a feature's value which decides if it should be implemented or not, to which its clear that definition checking provides huge value. If this feature could not be implemented at a transpiler level, then its understandable (which I think it can't be but I don't know enough about compilers).
So yes, unit tests are a viable fallback but the value that definition checking provides do justify it to be in the langauge (if it can be).

[JohelEGP]

See https://akrzemi1.wordpress.com/2020/09/10/concept-archetypes-update/#comment-35129
and https://akrzemi1.wordpress.com/2020/09/10/concept-archetypes-update/#comment-35131
with regards to having the compiler generate archetypes for you.
It's not easy.
That last comment also mentions C++0x concepts.

[AbhinavK00]

There was a GCC fork mentioned in Douglas Greg and Jeremey Seik's version of C++0x concepts papers called ConceptGCC though its probably can't be found anymore. This says nothing about whether they're easy or hard to implement but that's one proof of concept at compiler level, not at transpiler level. Archetypes are a nice way but I don't think they're necessary.
Warning: The following could be fully gibberish
Defintion checking can be thought as kind of mapping between operations in function body and expressions in concept body. For every operation/expression that you encounter in function body, you check the types involved, then from the constaints on those types, you map it to an identical expression in concept body. If you find an operation that could not be mapped after checking exhaustively, there's a violation.

N1848 section 4 also mentions archetypes, so they not be left out altogether, and generating archetypes, as you mentioned, is hard.
Maybe implementing definition checking is not feasible, in which case I'd be sorry for taking y'all's time in this discussion.
Edit: Maybe its still worth in case there is a way to implement definition checking or delay this feature for future implementation.

Here's some papers where most of my C++0x concept knowledge comes from, incase anyone wants to read
N1782
N1848
N1849
N2042

[hsutter]

ConceptGCC

Yes, that was "the" C++0x concepts compiler.

Let me try to distill the problems mentioned to what I understand to be the fundamental tension:

If you assume you have "concept maps" as an intermediate/wrapping layer, then:

• automated definition checking becomes feasible, the compiler can easily generate archetypes from the map interface; but
• you incur overheads:
  • you rely on the optimizer to be able to optimize that extra layer away well enough to not impact run times unacceptably
  • you rely on the compiler to do the checking fast enough to not impact compile times unacceptably

AFAIK nobody has get demonstrated a C++ system with concept maps that have acceptable run-time and compile-time overheads, so we don't know whether it's possible to achieve even in principle. I think Carbon is trying to achieve it, and I look forward to their new data!

Does that help?

[AbhinavK00]

Thanks for the detailed reply. You're right about absemce of a system with good enough definition checking for cpp, the only one that even exists out there is in circle and we don't know how good it is. So, I guess the result of this discussion boils down to "not worth implementing yet".
I think there's no need to discuss furthere(?), maybe about structural vs nominal debate, maybe?

[JohelEGP]

Definition-Checked Generics, Part 1: The Why & How - Chandler Carruth, Josh Levenberg, Richard Smith
-- https://www.youtube.com/watch?v=FKC8WACSMP0

This looks really promising.
Unfortunately, it seems like something for the Dart plan.

[AbhinavK00]

Unfortunately, it seems like something for the Dart plan.

The feature itself (or any feature for that matter) doesn't fall into the Dart plan (or the Typescript plan), it's how we implement it. Carbon itself is following the Dart plan so it'll look like it but if we could implement definition checking in cpp2, there will be a way to do that accordin to Typescript plan.

[JohelEGP]

Hopefully you're right!
But I'm erring on that side.
I believe there is a burden of proof.

[hsutter]

As Steve Jobs put it, "design is how it works." C++0x concepts could do definition checking because it was a different design (incompatible with C++20 concepts) that assumed the existence of concept maps.

The feature itself (or any feature for that matter) doesn't fall into the Dart plan (or the Typescript plan), it's how we implement it.

I'll push back on the 'how we implement it' part... Whether it's the TS plan or the Dart plan is all about whether it's 100% compatible (no-thunk no-shim no-indirection interoperable) and that only happens when that compatibility is adopted first as a fundamental constraint on the design (TS plan). It's not possible to create a new design for concepts and implement that (Dart plan), and then later figure out how to make it 100% interoperable; at least, not without starting over.

The key question is: Are they C++20 concepts, fully compatible but with a great idea for extending C++20 concepts to do definition checking? For example, can I write a definition check for std::semiregular itself? If yes, that's the TypeScript plan. Or are they non-C++20 concepts, an incompatible alternate design we should use instead of C++20 concepts that competes on its own design benefits? If the latter, that's the Dart plan. Not taking anything away here, both are valid plans, but personally I'm interested in pursuing only the TS plan here.

[AbhinavK00]

C++0x concepts could do definition checking because it was a different design (incompatible with C++20 concepts) that assumed the existence of concept maps.

Actually, the N1782 paper about C++0x concepts talks about definition checking without concept maps. This was probably Bjarne's original idea, definition checking was intended but with implicit mathing of a type to concept. Also, this the "concepts" mentioned in this paper are the ones that most closely resemble the cpp20 concepts (atleast one the surface). Now, this doesn't mean that defintion could just be implemented with impicit matching, it could be that wg21 came to conclusion that it could not be done and therefore later versions of C++0x concepts had concept maps. But I don't think that happened because N2906, the paper that Bjarne mentions as "Arguably, this was the paper that caused concepts to be postponed." also advocates for implicit matching of types to concepts.

I do agree with everything else you said.