[PATCH] D54565: Introduce `-Wctad` as a subgroup of `-Wc++14-compat`

Arthur O'Dwyer via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Dec 22 10:14:42 PST 2018

Quuxplusone added a comment.

> - using CTAD on arbitrary class templates that weren't designed for it creates a source compatibility problem that the class template author has no control over nor say in
> - using CTAD on class templates that were designed for it does not create a new source compatibility problem -- the class template author created the source compatibility problem themselves when they designed how their class templates would interact with CTAD

I don't see the distinction you're making. It sounds like you're saying, "`std::vector` is a 'CTAD-enabled' type. You (the client programmer) opted into CTAD when you started using `std::vector` in your project. If you don't want accidental CTAD, stop using `std::vector`" — which I don't think is practically useful advice.

> it would also seem like a good idea to have warnings for CTAD cases that we have strong evidence are dangerous (eg, for `T(x...)` where `x` expands to a pack containing a single `T`, we should warn if we use the copy-deduction candidate and there's another candidate that would have been selected if the copy-deduction candidate didn't get a priority boost)

That sounds like a good idea (although I am not qualified to implement it). I would also ask for a warning on `T t{x};` within a generic algorithm where `x` is of some dependent type that might or might not happen to be a specialization of `T`. And ideally we'd be able to produce the warning at parse time (i.e. generic-algorithm-testing time) rather than waiting until the offending template instantiation is actually instantiated (i.e. generic-algorithm-usage-in-the-field time), because by then it's too late for the client programmer to do anything about it.

For an (artificial) example of how accidental CTAD in a generic algorithm can cause interesting misbehavior, see https://quuxplusone.github.io/blog/2018/12/11/dont-inherit-from-std-types/#now-we-feed-them-to-this-functio

  rC Clang



More information about the cfe-commits mailing list