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

[Eric Fiselier via cfe-dev]

On Sat, Aug 3, 2019 at 10:54 AM Michael Spertus via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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.
>

>

As programmers start using this feature, I would be curious to learn what
percentage of existing class templates work with CTAD out of the box.
Especially class templates with more than one template argument.


> 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
>>
> _______________________________________________
> 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/b9e8376b/attachment.html>