rG36bb6d5d4673 (2017-12) switched Clang’s default C++ dialect from gnu++98 to gnu++14. I think it is perhaps time to switch to gnu++17 now. This will match GCC, which from 11 onward defaults to gnu++17.
I have noticed that Apple’s DriverKit (⚙ D121911 [Clang] Add DriverKit support) has defaulted to C++17. If we land it, the next major release 16.0.0 will have the change.
I am in favor of the switch, at least in principle. Clang’s C++17 support (Clang - C++ Programming Language Status) is almost complete, but the only entry that is marked as partial is Matching template template parameters to compatible arguments. It would be nice if this was fully supported, but I think making the switch can still proceed without it.
I think now is a good time to trial the switch, since we’re very early in the Clang 16 cycle, that should give people a chance to find any surprises that need to be dealt with.
The problem is that the flag as is in Clang today implements the feature to the letter of the law.
But that has proven in practice to break old and reasonable code. GCC implements their own tweaks to the rules to avoid those compatibility issues.
In that patch, I implemented a tweaking along these lines to avoid that breakage. As far as I know, it works. But in private conversation with zygoloid a long time ago, he suggested what seemed like a much better approach, but I did not have time to follow up on that.
Right now I have the resugaring project to finish, so I may not be able to get back to that very soon (within two months).
This removes my concerns about the “partial” status; we at least know what’s left to fix up and why and we’ve picked the approach that makes porting easier instead of harder.
FYI, Sony (PS4/PS5) might want to stay with 14, I’ve opened an internal ticket to make that decision. This should not be considered a blocker. It does raise the question whether all targets (that don’t use libcxx) have 17-compliant libraries.
Well, I use LIBCXX but my I found that some of the C++17 pieces want some POSIX stuff that my underying CRTL isn’t doing correctly. One of my FT sites pointed that out to me so we’re only supporting C++14 or lower right now on OpenVMS x86 until we sort it out. We don’t have lots of tests for these things running.