I’m currently testing 9.0.0 and I’m one of those strange people that uses -Weverything in production, as we only support a single clang-release at the same time. (Actually clang-cl, as it’s Windows-only)
During the upgrade, I’ve noticed a new warning “-Wctad-maybe-unsupported”.
At first, I was really happy seeing it and started updating some code that implicitly used it.
I’m even considering to propose an extension to our styleguide, as mentioned in the review of the warning: https://reviews.llvm.org/D56731
Some style guides want to allow using CTAD only on types that "opt-in"
However, after finishing my initial testing and applying some suppression and update locally, I’m changing my mind.
Over half of the updates I had to do were about
std::scope_guard … (and this without actively using this feature).
What do you mean by “without actively using this feature”?
It is unfortunate that this warning will flag types designed to work with CTAD, but who don’t need any explicit deduction guides.
Over time, I hope libraries that care about CTAD will address this by suppressing the warning manually; but that’s not an ideal solution.
These classes, if I’m correct, are one of the selling point of CTAD and are prohibited thanks to this warning.
They’re not meant to be triggered by this warning. It’s just an oversight.
I’ll update and audit libc++ to opt-in where needed. I’ll also set up libc++'s test suite to build with this warning
I’ll try to get the fixed into 9.0.
To circle back to title of the email, should -Wctad-maybe-unsupported actually be a compiler warning iso a clang-tidy check?
(You mean “should -Wctad-maybe-unsupported be a clang-tidy check instead of a compiler warning?”, I assume.)
If so, would it make sense of having a white-list, like all
The diagnostic is no less valid for types in the standard library. The library author should audit the type to ensure it’s CTAD safe, write tests, and then explicitly opt it in. This is
important for the correctness of client programs written using CTAD.
FWIW, I continue to believe that it makes no sense to talk about the library author “opting in” to CTAD.
Types have to be designed with CTAD in mine. Without explicit deduction guides CTAD often does the wrong thing.
Even otherwise unobservable qualities about how a constructor is lexically spelled in source can greatly impact CTAD.
Whether a template was designed to support CTAD is an important quality we should talk more about.
Either the client programmer trusts CTAD (even if it runs the risk of deducing the wrong thing sometimes) and thus every set-of-missing-angle-brackets must be assumed to be intentional no matter what type it’s on, or else the client programmer doesn’t trust CTAD (because of the aforementioned risk), and thus every set-of-missing-angle-brackets must be assumed to be unintentional.
This isn’t a dichotomy.
To be clear, “-Wctad-maybe-unsupported” diagnoses only usages of CTAD on types without any explicit deduction guides.
The intentions of the library author don’t matter at all in this equation.
Whether a type was designed with knowledge of CTAD in mind has a causal relationship with the correctness of usages of that type with CTAD.
As client programmer I don’t want to use CTAD on types that haven’t been changed since before CTAD was a feature.