3 ms·

For C++17, the only best thing for me was that you can destructure tuples and pairs with a simple syntax (when otherwise you needed to use std::tie) auto [

For C++17, the only best thing for me was that you can destructure tuples and pairs with a simple syntax (when otherwise you needed to use std::tie) auto [a, b] = functionThatReturnsATuple(); For C++20, the one single thing I'm excited about is designated initializers (which was already in C99! It's kinda mad why this came so late). Basically you can initialize structs with parameter names with just a single line of code: struct Person { std::string name; int age; }; Person person = {.name = "Bob", .age = 29}; Anything else from C++17 and onwards I really don't find a usage for right now. Compile-time programming using constexpr and consteval is great, until you realize that compile-time programming works under the hood by evaluating the AST directly (which is the slowest possible way for an interpreter), and would make your build times skyrocket to the moon. Concepts are kinda nice because of better error messages, but doesn't really matter for me if heavily templated libraries like STL and Eigen aren't fully ported for this feature. Ranges are just unnecessary for me, I learned the hard way that for loops are much better in terms of clarity and performance. And for modules: again, it only matters if the STL, tooling, and major libraries are ready for it, and I'm skeptical it will be achieved at any time.

dkersten 6y ago
For C++20, I agree with you on Concepts. They're nice to have, but its probably going to be quite rare that I will use them. I am, however, interested in coroutines and modules too (the other two of the three main things 20 adds). I also agree on the initializers, that's something I wish C++ had added long ago, since C has had it for so long. Funny thing is, I didn't even think of ranges while writing my comment above. I like the idea of them and they do allow some nice code, but its not something I've been wishing I had. For C++17, there's a bunch of small things that I like: standard attributes like [[nodiscard]], nested namespace definitions are a nice convenience, constexpr if statements and some of the library additions are nice (string_view, optional, etc). Destructuring auto, as you said. Nothing as exciting as what C++11 or 20 adds, but still nice to haves.
ncmncm 6y ago
If that is your favorite thing from C++20, I have very good news for you: You hain't seen nothin' yet. Saying concepts are just for better error messages is like saying types are just for error checking. You can rely on them only for that. Or you can put them to work. Most of what makes C++ powerful is from putting types to work. Concepts are just as powerful. You haven't seen yet what they can do.
- afranchuk 6y ago
  Agreed. They are the compile-time interfaces to templates' compile-time classes (so to speak, though obviously templates aren't limited to classes). I've been wanting them for so long; naturally error messages are better, but documentation will be better integrated/generated too. Just being able to understand what's expected of a templated type in a compile-time verified way is invaluable. I've taken to writing the concepts I'm using in comments (in the concept syntax) and can't wait to start uncommenting them.
  - ncmncm 6y ago
    Really, you can now overload based on concept matching, and so tailor implementations according to the family of types passed, analogously to overloading regular functions based on actual types, and overloading templates based on partial matches. Concepts are a fundamentally powerful tool. Haskell people will recognize them as akin to what they call type classes. Thus, in P2187 http://wg21.link/p2187 http://wg21.link/p2187 we have conditional swap that, for any small- and simple-enough type, is swapped using CMOV instructions instead of a probably badly-predicted branch. This mechanism works in released Gcc-10 today. (Note that what goes into the Standard Library will probably differ, in details, substantially from P2187R5.)
    - dkersten 6y ago
      > you can now overload based on concept matching Can you use this to compile-time detect if a class has a particular member function? I've used code like this before, and the implementation has always been a bit of a mess, so I wonder if it can be simplified with concepts: template <class T> void foo (T& t) { if constexpr (hasMemberBar<T>()) { t.bar(); } } Currently, I use this to implement hasMemberBar and I wonder if there's a better way now: https://gist.github.com/danielytics/8944b51ca51280fba30baab60a3e9d72 https://gist.github.com/danielytics/8944b51ca51280fba30baab6... Especially something that works without using the preprocessor, while still not needing a new implementation for each member I wish to check for.

dkersten 6y ago

For C++20, I agree with you on Concepts. They're nice to have, but its probably going to be quite rare that I will use them. I am, however, interested in coroutines and modules too (the other two of the three main things 20 adds). I also agree on the initializers, that's something I wish C++ had added long ago, since C has had it for so long. Funny thing is, I didn't even think of ranges while writing my comment above. I like the idea of them and they do allow some nice code, but its not something I've been wishing I had. For C++17, there's a bunch of small things that I like: standard attributes like [[nodiscard]], nested namespace definitions are a nice convenience, constexpr if statements and some of the library additions are nice (string_view, optional, etc). Destructuring auto, as you said. Nothing as exciting as what C++11 or 20 adds, but still nice to haves.

ncmncm 6y ago

If that is your favorite thing from C++20, I have very good news for you: You hain't seen nothin' yet. Saying concepts are just for better error messages is like saying types are just for error checking. You can rely on them only for that. Or you can put them to work. Most of what makes C++ powerful is from putting types to work. Concepts are just as powerful. You haven't seen yet what they can do.

afranchuk 6y ago
Agreed. They are the compile-time interfaces to templates' compile-time classes (so to speak, though obviously templates aren't limited to classes). I've been wanting them for so long; naturally error messages are better, but documentation will be better integrated/generated too. Just being able to understand what's expected of a templated type in a compile-time verified way is invaluable. I've taken to writing the concepts I'm using in comments (in the concept syntax) and can't wait to start uncommenting them.
- ncmncm 6y ago
  Really, you can now overload based on concept matching, and so tailor implementations according to the family of types passed, analogously to overloading regular functions based on actual types, and overloading templates based on partial matches. Concepts are a fundamentally powerful tool. Haskell people will recognize them as akin to what they call type classes. Thus, in P2187 http://wg21.link/p2187 http://wg21.link/p2187 we have conditional swap that, for any small- and simple-enough type, is swapped using CMOV instructions instead of a probably badly-predicted branch. This mechanism works in released Gcc-10 today. (Note that what goes into the Standard Library will probably differ, in details, substantially from P2187R5.)
  - dkersten 6y ago
    > you can now overload based on concept matching Can you use this to compile-time detect if a class has a particular member function? I've used code like this before, and the implementation has always been a bit of a mess, so I wonder if it can be simplified with concepts: template <class T> void foo (T& t) { if constexpr (hasMemberBar<T>()) { t.bar(); } } Currently, I use this to implement hasMemberBar and I wonder if there's a better way now: https://gist.github.com/danielytics/8944b51ca51280fba30baab60a3e9d72 https://gist.github.com/danielytics/8944b51ca51280fba30baab6... Especially something that works without using the preprocessor, while still not needing a new implementation for each member I wish to check for.