Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: DM
-
Labels:None
Description
With the use of the conda compiler toolchain, our compilers on all platforms have full C++17 support. This RFC proposes to update the DM C++ style guide to reflect this.
Updating to the C++17 standard allows us to use many fancy new features, in particular the inclusion of std::variant and std::visitor, which allows us to remove our dependency on boost::variant which does not seem to be actively supported.
There are also a number of previously deprecated and now removed features which are used in the stack. Jim Bosch and I have worked through these on the u/jbosch/c++17 branch to demonstrate the viability of upgrading our C++17 baseline.
Attachments
Issue Links
Activity
I'm in favor
I would really like to add something to the dev guide about how much C++17 to use in new code, and how. C++17 makes it significantly easier to write C++ in such completely different dialects that they don't even look like the same language anymore, and readability could really suffer if we don't try to reign that in.
That said, we've got so few people writing C++ these days (and the effort involved in including C++17 in our style guide at the same level of detail it currently has seems so hard), and I don't think I want to make that a precondition for adopting C++17. I would love to hear others' thoughts on how best to address that, though, especially how to deal with cases where new C++17 features might make our existing recommendations conflict with the prevailing external C++17 best practices.
I second Jim Bosch's concerns about readability. I haven't worked with C++17 myself, but from a quick review of the new features a lot of it seems geared toward making more things more implicit. This could make our code simpler (I don't think anybody will complain about nested namespaces), but also harder to understand (just what is the type of this structured binding where the source expression uses deduction guides from braced initializers? 
).
On the other hand, it is 2021, and it's a bit ridiculous for us to continue to insist that we should write "C++98 with extensions". That benefits neither old programmers (who will still be confused by occasional use of new features) nor incoming C++ experts (who will be hobbled by bans on the tools they're used to).
I think the only practical options are to stick to C++14 (much like how some astronomy projects still use Fortran 77) or to go through the effort of fully retraining ourselves for C++17. I realize this is the opposite of what I supported when we changed to C++14, but looking at some of the new rules (e.g., how moving behaves in C++11/14 vs. C++17) I no longer think we can pick and choose.
Krzysztof Findeisen
added a comment - - edited I second Jim Bosch 's concerns about readability. I haven't worked with C++17 myself, but from a quick review of the new features a lot of it seems geared toward making more things more implicit. This could make our code simpler (I don't think anybody will complain about nested namespaces), but also harder to understand (just what is the type of this structured binding where the source expression uses deduction guides from braced initializers? ).
On the other hand, it is 2021, and it's a bit ridiculous for us to continue to insist that we should write "C++98 with extensions". That benefits neither old programmers (who will still be confused by occasional use of new features) nor incoming C++ experts (who will be hobbled by bans on the tools they're used to).
I think the only practical options are to stick to C++14 (much like how some astronomy projects still use Fortran 77) or to go through the effort of fully retraining ourselves for C++17. I realize this is the opposite of what I supported when we changed to C++14, but looking at some of the new rules (e.g., how moving behaves in C++11/14 vs. C++17) I no longer think we can pick and choose. CCB are happy to adopt C++17 and Kian-Tat Lim will update the dev guide to indicate that C++17 solutions are preferred but to be careful about readability.
Eli Rykoff I believe that all the work on this RFC has been completed and we can now mark it as implemented.
I'm in favor of this given the compilers are already compliant and this will help the Apple Silicon port. It also sounds like a nice cleanup.