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 have put up a patch to do this: ⚙ D131465 C++/ObjC++: switch to gnu++17 as the default standard
What do you think of the transition?
Thank you for working on this!
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.
That feature is actually IMPLEMENTED, but hidden behind a flag at the moment. There IS a patch to remove the flag and make it default(⚙ D109496 [clang] deprecate frelaxed-template-template-args, make it on by default) but @mizvekov seems to have stalled on it?
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).
Thank you for the details, that’s good to know!
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.
@rjmccall – any concerns about switching ObjC++? I assume you’d want that in lockstep with the default C++ version, but I wasn’t 100% sure.
ObjC++ should definitely follow C++ for the default language version.
It won’t affect most ObjC++ users anyway because I believe Xcode always passes a
Thanks for the confirmation!
Thanks to every one for discussions.
C++/ObjC++: switch to gnu++17 as the default standard landed today as rGe321c8dd2cea