>The only benefit of them seems to be slightly better error messages if someone misuses a template class/function.

The error messages are arguably worse with concepts than without them but it's really just a trade-off. Without concepts you got long "stack-traces" of raw syntax errors that could dig deep into nested functions. With concepts you get long stack-traces of concept failures where concept A fails because concept B fails because concept C isn't satisfied and then you need to dig through this chain of concepts to figure out what's actually needed.

Traits in more principled languages like Haskell/Rust don't have this issue whatsoever because traits are semantic requirements in those languages while concepts in C++ just perform a "will it compile" kind of check.

The primary benefit of concepts in C++ is overload resolution, they allow you to write multiple functions with the same name, and same number of parameters, but where the types of the parameters are required to satisfy certain properties.

For example:

    void serialize(std::ranges::contiguous_range auto&& range) {
      // Serialize the underlying memory directly
    }

    void serialize(std::ranges::range auto&& range) {
      // Serialize elements individually
    }

I'm not a Zig expert but it looks as though the intent is that duck-typing is not a core part of this idea. Having traits allows Carol to implement Ben's Teleport trait for Alice's Goose.

With duck-typing Carol needs to either prevail upon Alice to make you a teleporting Goose, or make her own "CarolsTeleportingGoose" wrapper type which implements the teleporting functions.

Concepts are predicates for types, that is, functions from types to booleans. Everyone was already defining templates like is_contiguous_range<T>::value so much that they decided to give it first-class status in the language.

The really cool part about concepts (unless you're writing the compiler) is actually requires expressions, which can replace a lot of SFINAE.

Concepts are great for overload sets where previously you needed enable_if gymnastics. Also useful for if constexpr.

If you do template metaprogramming it makes your life a lot easier.

> The only benefit of them seems to be slightly better error messages if someone misuses a template class/function.

Seems like a pretty valuable benefit?

The benefit to C++ is that it’s actively trying for as many features as possible, keeping out of reach full support from any compiler. Maybe GPT-8 will be the first true C++ expert, built by the first superintelligence GPT-7.

That was a mistake on my part. Thanks for catching. Fixed.

Complexity budget and all that. But I'd sooner throw out inheritance than traits.

In Zig's case, it's compile time. An expression like `foo.bar(1, 2)` can only compile if `foo` has a method named `bar` with the right number of arguments. In a duck-typed system, `foo` can be any type of value you like, as long as it "fits" the shape.

In contrast, many languages require you to describe the shape up-front, and then constrain `foo` to implement that shape. For instance, in Rust we would have to write something like `trait Bar { fn bar(a: u32, b: 32); }`, and then say something like `foo: T where T: Bar`, before we're allowed to call the `bar` method.

Both are compile-time safe, but one requires more ceremony (but is more explicit), while the other is simpler (but you might have to guess the requirements).

> isn't that dynamic inheritance? The seems like dynamic runtime.

Duck-typing can be implemented with static checks, and doesn't require inheritance to be involved at all.

It's ad-hoc inheritance (but really subtyping more generally).

The dynamically typed version is dynamic inheritance, or really just dynamic attribute lookup.

The statically typed version is "generic programming" with templates. See for example the way that C++ standard library sort works.