[cfe-dev] Challenging "-Wctad-maybe-unsupported" for 9.0.0

[Michael Spertus via cfe-dev]

I see it as very much like FTAD, which also has no explicit opt-in
mechanism, and client programmers who omit template argument lists for
function templates also run the risk of deducing the wrong thing sometimes
(my upcoming CPPCon talk includes examples of this). In both cases, the
sign that the client programmer intends to rely on deduction is that they
omit the template argument list.

I'm not surprised you didn't find the warning to be very helpful, and I
predict the percentage of spurious warnings will only increase as
programmers become more comfortable with deduction for constructors
templates like they are for other function templates.

On Sat, Aug 3, 2019 at 9:14 AM Arthur O'Dwyer via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Sat, Aug 3, 2019 at 6:03 AM JVApen via cfe-dev <cfe-dev at lists.llvm.org>
> wrote:
>
>> Hello all,
>>
>> 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::unique_lock`,
>> `std::scope_guard` ... (and this without actively using this feature).
>> These classes, if I'm correct, are one of the selling point of CTAD and
>> are prohibited thanks to this warning.
>>
>> 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 `std::`
>> classes?
>>
>
> FWIW, I continue to believe that it makes no sense to talk about the *library
> author* "opting in" to CTAD. 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. The
> intentions of the *library author* don't matter at all in this equation.
>
> The situation for me is exactly analogous to VLAs in C — including the
> shape of the workaround: "write an explicit call to malloc()" versus "write
> an explicit call to make_foo()".
> https://reviews.llvm.org/D54565 implements a `-Wctad` warning analogous
> to `-Wvla`.
>
> –Arthur
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190803/a9bd7046/attachment.html>