C++20 Concepts: The Definitive Guide

Sort of, in that they are a thing you do to constrain generic parameters.

A significant difference in my understanding is that type classes and traits are required, but concepts are not. That is, using the example from the article, a concept can tell you if you're passing something that doesn't add, but you can add inside a function without using a concept. In other words:

    fn add(x: T, y: T) -> T {
        x + y
    }

This won't compile in Rust:

    error[E0369]: cannot add `T` to `T`
     --> src/lib.rs:2:7
      |
    2 |     x + y
      |     - ^ - T
      |     |
      |     T
      |
    help: consider restricting type parameter `T`
      |
    1 | fn add>(x: T, y: T) -> T {
      |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    

This suggestion works, but you don't have to write it this way. Once the constraints get more complex than T: Foo, I personally switch to this form:

    use std::ops::Add;
    
    fn add(x: T, y: T) -> T
    where
        T: Add,
    {
        x + y
    }
    

I find it a little easier to read. YMMV.

Whereas in C++, this does compile:

    template
    T add(T a, T b)
    {
      return a + b;
    }

If you try to add something that doesn't have + defined:

    int main(void) {
        add("4", "5");
    }

you get this

  :4:12: error: invalid operands to binary expression ('const char *' and 'const char *')
    return a + b;
           ~ ^ ~
  :8:5: note: in instantiation of function template specialization 'add' requested here
      add("4", "5");
      ^

Whereas, if you do what the article does (though I'm using char* instead of std::string, whatever)

    #include 
    template
    concept integral = std::is_integral_v;
    
    template
    T add(T a, T b)
    {
      return a + b;
    }
    
    int main(void) {
        add("4", "5");
    }

you get

    :12:5: error: no matching function for call to 'add'
        add("4", "5");
        ^~~
    :6:3: note: candidate template ignored: constraints not satisfied [with T = const char *]
    T add(T a, T b)
      ^
    :5:15: note: because 'const char *' does not satisfy 'integral'
    template
                  ^
    /opt/compiler-explorer/gcc-11.1.0/lib/gcc/x86_64-linux-gnu/11.1.0/../../../../include/c++/11.1.0/concepts:102:24: note: because 'is_integral_v' evaluated to false
        concept integral = is_integral_v;
                           ^

This doesn't feel like a huge change because add is such a small function, but if it were larger and more complicated, the error with a concept is significantly better.

How can floats be totally ordered. This isn’t even a matter of NaNs or not. A set of floats where two or more floats compare equal does not permit a total ordering.

C++23 vs C++20 seem to be less drastic. So maybe they will slow down to a slow trickle at some point ;)

-0.0 and +0.0?

The most important thing to say about this "definitive guide" is that it delays to the end presenting the overwhelmingly most important detail about Concepts: how to use them.

The right place to put a concept name, in production code, is in place of "typename" in a template definition, or even better in place of "T" in the function argument declaration. That is, instead of

  template
  T add(T a, T b)
      requires addable (
    return a + b;
  )

say

  template 
  T add(T a, T b) {
    return a + b;
  }

or

  auto add(
      addable auto a, 
      addable auto b) {
    return a + b;
  }

according as whether you want to enforce a and b to have the same type (which is another omission).

Most often it is not necessary, and not wanted, to enforce a and b having the same type.