C++20 Concepts: The Definitive Guide
thecodepad.com
thecodepad.com
Concepts, just like the SFINAE and constrexpr hacks you should discard in their favour, are about only what will compile and you, the C++ programmer, are always responsible for shouldering the burden of deciding whether that will do what you meant even if you have no insight into the types involved.
Example: In C++ the floating point type "float" matches a concept std::totally_ordered. You can, in fact, compile code that treats any container of floats as totally ordered. But of course if some of them are NaN that won't work, because NaNs in fact don't even compare equal to themselves. You, the C++ programmer were responsible for knowing not to use this with NaNs.
Whereas, Rust's floating point type f32 implements PartialOrd (saying you can try to compare these) but not Ord (a claim that all of them are totally ordered). If you know you won't use NaNs you can construct a wrapper type, and insist that is Ord and Rust will let you do that, because now you pointed the gun at your foot, and it's clearly your fault if you pull the trigger.
This is a quite deliberate choice, it's not as though C++ could have just dropped in Rust-style traits, but I think a "Definitive Guide" ought to spell this out so that programmers understand that the burden the concept seems to be taking on is in fact still resting firmly on their shoulders in C++.
The other side of this is, if you wrote a C++ type say Beachball that implements the necessary comparison operators the Beachball is std::totally_ordered in C++ 20 with no further work from you to clear up this fact. Your users might hope you'll document whether Beachballs are actually totally ordered or not though...
I think this will likely prove to be a curse, obviously its proponents think it will work out OK or even a blessing.
[0]: https://en.cppreference.com/w/cpp/utility/compare/partial_or...
Specifically these ordering classes are the result of the spaceship operator and the concept doesn't care whether you have a spaceship operator.
(This is a serious question I honestly don't know.)
Thanks for clearing that up!
Of more moment is that floating point variables often represent imprecise values, such that e.g. 1.41 could represent a value that should equal another transcribed as 1.39. The type system will not help you there. You are obliged to code in tolerance the hard way.
Floating point numbers have a dedicated sign bit that specifies the sign, which means that you can flip the sign of any floating point number and get a float with a different bit pattern (and opposite sign). That means that you get necessarily get both +0.0 and -0.0, and they have different internal representation in bits.
This is one of the major advantages of two's complement notation for representing integers: it doesn't have a dedicated sign bit in the same way, so you only get one representation for 0. You can still check the sign by looking at the top bit, but if you flip it for the number 0, you don't get -0 (which doesn't really exist), you get -128 (for 8 bit signed integers).
[1]: https://en.wikipedia.org/wiki/Double-precision_floating-poin...
> Concepts, just like the SFINAE and constrexpr hacks you should discard in their favour, are about only what will compile and you, the C++ programmer, are always responsible for shouldering the burden of deciding whether that will do what you meant even if you have no insight into the types involved.
To be fair, that's not what makes them different from Rust. Unless there's something in Rust that I missed, it offers no guarantees that the implementation of the trait is consistent with its semantics.
Whether it's traits or concepts, it's still about compile-time type-checking, not actual contracts.
So in C++ the fact a Mouse is food::LovesCheese doesn't actually tell me whether the Mouse's programmer has any idea what it means to food::LovesCheese or whether the food::LovesCheese programmer knows about a Mouse. I need to carefully read the documentation, or the source code, or guess. It might be a complete accident, or at least an unlucky side effect.
In Rust the fact a Mouse has the trait food::LovesCheese always means specifically that either (1) the Mouse programmer explicitly implemented food::LovesCheese as part of a Mouse or (2) the food programmer explicitly implemented a way for Mouse to food::LovesCheese. Rust requires that nobody but them can do this, if I have a Mouse I got from somewhere but alas it doesn't food::LovesCheese and I wish it did, I need to build my own trivial wrapper type MyCheeseLovingMouse and implement the extra trait.
Either way as the user of any Mouse, you can be sure that the fact it has food::LovesCheese in Rust is on purpose and not just an unfortunate behaviour that nobody specifically intended and you need to watch out for.
Thank you for clarifying.
Bearing this in mind, neither concepts in C++ nor traits in Rust guarantee any semantics in the Rust sense of the word. In the C++ sense of the word, C++ concepts do carry guarantees, in that the spec says what they should do. But, in this sense, so does Rust: PartialEq [1], for example, has semantic requirements spelled out in the documentation. In my mind, the difference is that Rust programmers tend to program defensively, not trusting programmers to get things right that the compiler doesn't enforce. Thus you see a lot of conversations along the lines of "what if the implementer of trait X does something weird?" in the Rust space. This may give the impression that Rust traits don't have a clear and consistent semantics associated with them. But that's not right: the implementer of PartialOrd, for example, is absolutely expected to implement a proper partial order, as explained in the documentation. A specification for Rust could specify associated semantics for those traits, just like in C++.
That option isn't available to C++ because of how concepts work. PartialEq and Eq wouldn't be different concepts in any practical sense, they would just be a funny way to write a comment, but in Rust they are different traits because even though Eq doesn't add any syntax it does add semantics.
There is one further trick I wasn't going to mention but you've sort of brought it up. Rust's unsafe is partly about taking responsibility for the safe and correct operation of your code. That's a pretty alien thought in C++ although I argue it shouldn't have been, it's clearly too late now. As a result Rust has the idea of unsafe traits. If you get PartialEq wrong, the programmer using your type curses and probably discards it as hopelessly broken, but their program mustn't have Undefined Behaviour as a result by Rust's definition.
However if you implement an unsafe trait like Send wrong, maybe the program now has Undefined Behaviour, as a result (signalled by the unsafe keyword you'll need to use to implement it) you are responsible for making sure your implementation is in fact semantically correct.
This distinction wouldn't mean anything in C++ where not only are your implementations of concepts never required to obey the semantics, but the language doesn't even allow you express that your implementation doesn't obey the semantics, the fact it's a syntactic match means it gets recruited by the concept and too bad.
What use would that be to a C++ developer who doesn't know rust?
As you see from the standard library concepts the emphasis is on semantic claims like "fully ordered" but this feature does not actually provide semantics and I think that's a trap programmers would be likely to fall into.
template <typename T>
struct totally_ordered : std::false_type {};
Then you can define a TotallyOrdered concept that requires the trait.
The C++ standard library didn't do this, so if you happen to accidentally implement a type with an API that conforms to TotallyOrdered, then it becomes "accidentally" TotallyOrdered, which is a big footgun.
If your Delicious concept mistakenly applies to my Desert, how do I as the author of the Desert tell C++ "No, no, when people ask if a Desert is Delicious tell them it isn't?".
There is no way for a class to both implement the concept API and opt-out. The only way to support it is for the C++ concept writer to make their concept opt-in.
test.cpp: In instantiation of ‘T add(T, T) [with T = std::basic_string<char>]’:
test.cpp:17:21: required from here
test.cpp:11:22: error: static assertion failed
11 | static_assert(std::is_integral_v<T>);
| ~~~~~^~~~~~~~~~~~~~~~
test.cpp:11:22: note: ‘std::is_integral_v<std::basic_string<char> >’ evaluates to false
I agree this is great news. I actually had to write MS SQL for the first time last week and it was disappointing but sadly expected to have it respond to a common but not technically-standard SQL syntax I'm used to with "Syntax error" as though somehow that's helpful. Such poor errors meant I spent more time reading the documentation than writing queries even though I've years of experience across several other SQL dialects.
See https://clang.llvm.org/diagnostics.html ; that page is not dated, but compares to gcc 4.9, which is from April 22, 2014.
gcc also has worked on improving its error messages (most likely because of competition with clang), so that comparison probably isn’t accurate anymore.
Clang concepts were implemented by one guy.
Apple doesn't really care about C++20. Their LLVM efforts are focused on Objective-C and Swift.
C++ as used on Apple platforms is mostly related to the Metal Shading Language (a C++14 subset) and IO/Driver Kit (an Embedded C++ variant).
Google has their style guide, only recently updated to C++, isn't a compiler vendor and apparently losing on the ABI vote has made several employees move away from their clang involvement.
Then the other vendors like Intel, Embarcadero, IBM, Codeplay, Sony, Nintendo, ARM, NVidia, AMS have their own agendas and do not upstream everything.
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<typename T>
T add(T a, T b)
requires addable<T> (
return a + b;
)
template <addable T>
T add(T a, T b) {
return a + b;
}
auto add(
addable auto a,
addable auto b) {
return a + b;
}
Most often it is not necessary, and not wanted, to enforce a and b having the same type.
That really depends on what you're trying to do. Presenting these two different declarations as somehow equivalent is very misleading and I'm glad that the author didn't do that.
The author's failing was in presenting neither of them until long after they were due, and presenting thoroughly inferior alternatives in the meantime.
Sometimes I think C++ would be better off if the committee stopped accepting proposals that add new features.
The additions since he bowed out improve the experience of production coders.
If you approach features in terms of how they can be useful when coding, almost all of his difficulties never arise, or are easily sidestepped. For working coders that becomes second nature.
I agree. Somewhere in the piled-high-and-deeper complexity of C++ there is one excellent, modern language that could be carved out.
Maybe it is only the subset since C++17.
Rather than something as coarse as epochs, C++ includes a lot of fine grained feature test preprocessor definitions such as (to pick one at random) '__cpp_lib_constexpr_algorithms'.
It's harder to make this work with breaking API changes of course. I assume non-preprocessor versions that work with modules will be available in C++23...and perhaps they will support API changes?
API changes that change semantics are forbidden in Standard interfaces, although APIs can be extended, backward-compatibly. To make an actual change, we need to introduce a new name. Thus, when we get around to modernizing std::vector, the fixed version will have a different name, maybe std::vec, but conceivably std2::vector.
I don't know of any plans for feature test macro analogs that would integrate with modules.
To be usable, epochs would have to apply locally to a file, not to anything #included into that file, nor to any file #including it. And, it should be possible to tie them to modules, to say "you can use this module only from code in epoch C++XX or later".
Let us hope that if such a name transition ever happens that the hideous plague of multi-case identifiers does not infect the standard. Leave that to (a subset of) user code.
Either std26::vector or std::vec would work for me. `std26::vec` would probably be better because of possible confusion (as to which vector implementation is desired) due to use of `using` directives.
What is the plan, if any, for deciding at compile time whether the format module is available or if I would still have to use fmtlib/fmt?
Nine to twelve years seems like it should be enough time to adjust.
First, you don't have to use the new features (though eventually you'll be reading the code of people who did, so this is only half-valuable). There is new c++11 code being written every day -- in volume (a hard to pin down amount) it's sadly more than 50%. The usage surveys don't really capture this clearly (and it's not clear they could).
Second: often new features are for library writers, or are out there for library writers to use (e.g. coroutines, which probably will not be appropriate for many users before c++23, but pretty much need to be available for people to experiment with).
Third: the new features tend to be additive. For example you don't need to use many of the stuff in <algoritm> -- stick to a for loop unless you want to take advantage of some new capability (e.g. policies, which are't ubiquitous). Concepts are the same way: they will improve error messages and reduce bugs, but if you don't use them your code will in 99.9% work just fine. When you see a very simple example that uses concepts, it's not surprising that the concepts don't really improve a simple add function -- the case is deliberately simple for explanatory purposes.
Languages move forward. Even go recently caved and added in generics.
The new features are there to improve your experience, and to make your code more reliable. When you have a choice between old and new, new is usually better.
Sticking to K&R, you would have as many bugs and crashes as other K&R code. Sticking to modern C++ makes most of such bugs impossible. That is progress.
You can stop learning and take up complaining at any time, as you have done.
But you can also start learning again at any time. Now is always a good time for that.
But it complicates the compiler, complicates the tools, complicates the error messages,...
Take something as "simple" as operator overloading. If a beginner does a "5"+5, the compiler is forced to respond with "no operator + for the types given, types are: int, std::string" instead of the infinitely more friendly "can't add string to int". I actually _like_ operator overloading, I wish more languages stopped the silly practice of making language-provided primitives somehow sacred and closed-to-extension. But look at how even this relatively straightforward and useful feature ruined the error message.
Part of this particular example is bad error message design. I mean, what are the chances somebody intended to do operator overloading but then forgot to implement the method? It would have been much better to say "Can't add string to int, Did you forget to implement operator+(.. .,...)?". This centers the common case first, then reminds the experienced about what could have happened in their case. But even this might confuse beginner and convince them that "5"+5 is somehow a reasonable thing to say (because it actually is in some contexts) that they just need to get that fabled operator+ from somewhere to make it work, instead of just outright telling them " nonsense, not gonna work".
Extensions are always, inherently, abstractly, a tradeoff. Because even if you are a perfectly spherical coder who doesn't interact with other code in any way, you at least interact with the language tools. And the tools _must_ know all the of the language: instead of just having the luxury to say "sorry mate can't do that" when encountering "5"+5, the editor/IDE/compiler has to spend the cycles to see if it _can_ do that, then report a message that simultaneously says that you can but can't. As the features accumulate and interact, the tradeoff curve increasingly inflect against adding new things.
All of this in the abstract is a fairly balanced argument that applies to any language, the particular case of C++ is much, much worse. C++ have this aweful way of "retconning" new features. I can never put my hands on it, but C# creators practically design a new superset every major version and call it the same name without ever making people angry or afraid that the language is spiraling out of control, but every C++ feature gives me this dark feeling of "is this never ever going to end? how far are you willing to take it?".
Part of that is undoubtedly the syntax, remind me again what language class (regular, context free,..) is C++ syntax? The other day I was fooling around and thought of adding discriminated unions to C++, just a thin syntax layer over a more verbose idiom. The very first thing is to parse the damn thing, but that way lies madness. Because C++ have no agreed-upon, guaranteed formal grammar. There is a grammar online but it's gargantuan and was written by one man, there is a grammar in the standard but it's gargantuan and the standard says it's there for illustration only, there is a grammar (implicitly) in the source code of any working parser but it's gargantuan and full of hacks. So for all practical intents and purposes, C++ has no formal grammar. Think about that for a minute, a formal language that has no formal grammar. It's the bare minimum any formal language can have, and yet you can't do it safely because of the massive, beast-like bloat that is that language.
You are not allowed to overload operators involving only built-in types so operator overloading changes nothing about the expression "5"+5. Even if you could overload operator+ here, there is nothing preventing a compiler from giving you the friendly explanation if that operator does not exist (perhaps with an additional hint that it could be defined).
(Also, the expression "5"+5 is valid C++ but Clang has -Wstring-plus-int to warn you that it might not do what you expect.)
I haven't used it much yet, but I would still say it is pretty good although far from a proper template type system.
no, people were writing "concept-like" code since C++98 in a very bloated way with e.g. sfinae, this is just standardizing existing practice (while improving it of course)
They are not though - the equivalent C++17 would be
template<typename T>
std::enable_if_t<std::is_intregral_v<T>, T> add(T a, T b)
{
return a + b;
}
I mean sure you can extend any commutative group into a module over the integers but you probably don't want to make this a hard requirement just to have subtraction.
If you want to define the concept of subtraction then you probably don't want to assume you can multiply elements with an integer. Not that it can't be done but in general it will be a lot easier to define the additive inverse directly (if one exists).
I mean if we move into different coordinates and different fields, then yeah things change, but I don't see what the issue is with the example given here.
It can then also be convenient to have a special type/value Origin, which (while functionally identical to point(0, 0)) allows you to e.g. write vector = point - origin to clearly express your intent of turning a vector into a point.
-1 * origin is not meaningful, but point - origin is (while point + origin is not).
<code> template<typename T> T mul(T a, T b) { return ab; }
template<typename T> T mul(T a, int b) { std::string ret_val{std::move(a)}; a.reserve(a.length() b); auto start_pos{a.begin()}; auto end_pos{a.end()}; for(int i = 0; i < b; i++) { std::copy(start_pos, end_pos, std::back_inserter(a)); } return ret_val; } </code>
I knew it looked odd to me for some reason...I had to re-write it as follows:
<code> template<typename T> T mul(T a, T b) { return ab; }
template<typename T> T mul(T a, int b) { std::string ret_val{}; ret_val.reserve(a.length() b); auto start_pos{a.begin()}; auto end_pos{a.end()}; for(int i = 0; i < b; i++) { std::copy(start_pos, end_pos, std::back_inserter(ret_val)); } return ret_val; } </code>
Did I miss something??
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<T>(x: T, y: T) -> T {
x + y
}
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<T: std::ops::Add<Output = T>>(x: T, y: T) -> T {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
use std::ops::Add;
fn add<T>(x: T, y: T) -> T
where
T: Add<Output = T>,
{
x + y
}
Whereas in C++, this does compile:
template<typename T>
T add(T a, T b)
{
return a + b;
}
int main(void) {
add("4", "5");
}
<source>:4:12: error: invalid operands to binary expression ('const char *' and 'const char *')
return a + b;
~ ^ ~
<source>:8:5: note: in instantiation of function template specialization 'add<const char *>' requested here
add("4", "5");
^
#include <concepts>
template<typename _Tp>
concept integral = std::is_integral_v<_Tp>;
template<std::integral T>
T add(T a, T b)
{
return a + b;
}
int main(void) {
add("4", "5");
}
<source>:12:5: error: no matching function for call to 'add'
add("4", "5");
^~~
<source>:6:3: note: candidate template ignored: constraints not satisfied [with T = const char *]
T add(T a, T b)
^
<source>:5:15: note: because 'const char *' does not satisfy 'integral'
template<std::integral T>
^
/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<const char *>' evaluated to false
concept integral = is_integral_v<_Tp>;
^
There was no header file hell. Often you didn't need a single header to be included in your code: most functions returned int (or nothing), and if you needed something that returned double, you could just say so.
I remember being excited about function prototypes, but something was irretrievably lost at that point. The primal elegance of C as it was conceived by its creators is long forgotten now.
(If you want, you can still experience it with the Tiny C Compiler that seems to continue to understand K&R C code just fine.)
You will enjoy Go.
Go can be understood as an improved, modernized C that doesn't abandon C's simplicity.
Go has a sophisticated runtime with transparent N:M threading and built-in concurrency primitives, Interfaces, garbage collection and a large standard library.
Go is only simple when compared to the other languages that sit in a similar space, like Java and C#.
This is false, because Go has a garbage collector by default. This isn't an "improvement" in anyway but for those who don't care about memory management and predictable and deterministic performances.