I've done some pretty involved concept work. I made this CBOR implementation that heavily uses concepts: https://github.com/absperf/conbor/blob/main/conbor/cbo

I've done some pretty involved concept work. I made this CBOR implementation that heavily uses concepts: https://github.com/absperf/conbor/blob/main/conbor/cbor.hxx https://github.com/absperf/conbor/blob/main/conbor/cbor.hxx (Warning: I abandoned this mid-development. It "worked" for most of my uses, but many things were dropped in mid-development) I ended up abandoning it because recursive concepts weren't universally functioning (clang didn't support them right), and more nefariously, the C++ name definition rules made a whole lot of things very very painful. concepts were evaluated based on their definition site, not based on names available where they were expanded. This is true of templates too, but in concepts, it prevented me from allowing users to effectively extend my concepts-based library, and some circularly-dependent concepts were impossible without a dummy "Adl" type to allow ADL to function. There are a lot of little places where the extent to which concepts work is entirely dependent on their order. In simple cases, concepts allow you to do things similarly to Rust traits and get some of those powers, but in C++, a lot of little frustrations keep it from being as ergonomic or as powerful, and you still have to play stupid C++ name lookup games. I remember a LOT of little annoyances, as well, in trying to partially constrain concepts, or express recursive concepts (which are very necessary for parsing a recursive format like CBOR). I tried a simple JSON parser that only allowed arrays and strings using C++ concepts and hit the same kinds of problems. I'd recommend using concepts, I think, but keep in mind that trying to do anything at all generic or extensible might cause you to do more C++ detangling than you want.