Concepts: The Future of Generic Programming [pdf]

Even though they aren't here, auto parameters, constexpr if, static_assert, and enable_if can already simplify some of those errors.

Warning: // 1990s style generic code: from the article describes me and C++, though I do understand more modern C++ at a basic level, I'm not an expert. You might say I'm.... rusty...

ahem.

One huge difference in general between C++ templates and Rust's generics (I _believe_ Java/C# are more like Rust here, and I'm not sure about Swift) in that C++ templates generally don't check that their calling code actually supports the type that's passed into the template. In other words, the check happens after the template is expanded. (This is the sort example on page 3). Rust's generics system does the opposite: it requires that if you call a method on some generic parameter, that generic parameter is constrained by a trait that has that method. This happens before expansion. So concepts are, in some ways, an attempt to make the C++ system closer to Rust's system. (This is ignoring the actual chronology here, of course: concepts have been in development a long time).

The way "requires" works here is very different than in Rust, as well. In Rust, you define a trait the same way you'd define regular methods. If those methods have a body, then it's used as a default implementation, if it does not, then you must implement that method. The equivalent of "must have an iterator type" is associated types, you add "type Name;" instead of a method signature.

So the equivalent of the "Sequence" type on page 7 would be

  trait Sequence {
      type Value;
      type Iterator<Item=Value>; // Iterator itself has an associated type, Value
    
      fn begin() -> Self::Iterator;
      fn end() -> Self::Iterator;
  }

roughly speaking. I don't think this exactly works, but just to give you some idea of how the syntaxes roughly compare. In general, I know that a Sequence trait in Rust would require higher kinded types or associated type constructors, which Rust does not yet have, and so the concept is probably not directly expressible.

That's my impressions after reading this. I have been meaning to read about concepts for a while, but since I only have so much time, have mostly waited to see how they shake out before really digging in. It's slightly slower going since my C++ isn't spectacular. This post mostly represents my understanding of the differences, I'm not trying to make any judgements here, etc.

Concepts are similar to Rust Traits, (I think) Swift Protocols and Haskel Type Classes, but different (significantly more expressive) than Interfaces.

The name has been used in the C++ community since at last mid 90s as it originated from Alex Stephanov work on the STL. Stephanov himself might have used the name even earlier than that. Formalization of concepts which has been attempted at least since the early 00s was influenced by Haskell and in turn did influence both Rust and Swift.

That is more related (not the same) to Java/C# Generics than Interfaces.

That is, it is resolved at compilation time and not at run-time as these that you cited except for some cases in Rust where Traits can be both run-time or compile-time depending on how you use them.

For decades C++ has the equivalent of these, it is called virtual pure classes (we may even consider virtual in general).

Besides what the others have replied, C++ already has interfaces, they are pure base classes (virtual if destructors are required).

But those cannot really fulfill the role of concepts in templates.

This is how I see Rust and why I really like it. As a car analogy, basically under the hood it has the C and C++ engine (more true yet using all llvm optimzations for clang) but it has more modern Teslaish/Ferrarish body. :)

  trait Foo { } // pretend this has methods

  fn static_dispatch<T: Foo>(x: &T) {}
  fn dynamic_dispatch(x: &Foo) {}

    fn dynamic_dispatch(x: &virtual Foo) { }

    fn static_dispatch(x: &Foo) { }
    // is just syntactic sugar for
    fn static_disatch<T: Foo>(x: &T) { }

What you're talking about is dependent types (https://en.wikipedia.org/wiki/Dependent_type). The problem with these is that, in general, determining whether or not an object is of one of these types (PositiveNumber, PrimeNumber, ListWithAtLeastThreeElements, etc.) at compile time is undecidable. This isn't horrible, as template meta-programming already allows you to encode Turing Complete programs into compilation, but unlike templates, where evaluation is somewhat straightforward, evaluating dependent types requires general theorem proving. There are languages with dependent typing, but of them I only know Coq, and Coq sidesteps the issue by the language not being Turing Complete.

What you're describing is more in the domain of program verification,

there's already work like this, for instance dafny [1], where you can have functions like this:

    method Abs(x: int) returns (y: int)
       ensures 0 <= y
    {
       ...
    }

or:

    method MultipleReturns(x: int, y: int) returns (more: int, less: int)
       requires 0 < y
       ensures less < x < more
    {
       more := x + y;
       less := x - y;
    }

[1] https://www.microsoft.com/en-us/research/project/dafny-a-lan...

You can do this with coq/agda/idris (fully general dependent types) or Haskell (LiquidHaskell). Not C++.

LiquidHaskell is nice because it's all written in comments next to or in a separate file from your Haskell code. This means the Haskell compiler doesn't even have to know about it. On the other hand, when you're using something like Idris for formal programming, you often find your program full of proof witnesses that you aren't actually using for your real code you want to write. You can prove all sorts of things, like that a function only returns negative multiples of 3, or only returns vectors of length 5n+1.

I believe the contracts (preconditions, postconditions, assertions) proposal may address this issue.

The latest proposal is P0380, "A Contract Design": https://wg21.link/P0380.

An earlier work, "Simple Contracts for C++" (https://wg21.link/P0287), gives some further background and motivation.

Notably, contracts are currently solely in the proposal stage (and not in the upcoming standard).

The failed C++0x proposal did include axioms that would have allowed the specification of such constraints, but axioms werent supposed to be checked by the compiler itself (other than syntactic correctness). Axioms were intended to be used for documentation and checked by static/dynamic analysers and possibly used for optimisations.

The current concept proposal is significantly reduced in scope and doesn't include anything like axioms.

Besides what everyone else is replying about dependent typing, you can get that in C++ by a mix of concepts, classes and operator overloading.

It isn't as clean, but it does the job.

For example you could have a PositiveNumber class, with the mathematical operators overloaded that always validated the invariant of the number being positive.

You just described dependent types, they´re available in Idris.