rsmith added a comment. >> I think there is a case to be made for warning on this specific language >> feature, because using CTAD on class templates that weren't designed for it >> is dangerous and creates source compatibility problems for future changes to >> that library. > > Personally I would go stronger: using CTAD on class templates that were > designed for it (1) is dangerous and (2) may create source compatibility > problems for future changes to that library!
I've given this a lot of thought, and while I'm very sympathetic to your desire here, I do not think that we have sufficient justification to provide a warning to allow (effectively) disabling this language features. There's an important difference here: - 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 Either way there's a source compatibility problem, but in the second case, it's the class template author's choice to extend their source compatibility contract. So: - I still think it's a good idea to have a warning to warn on use of CTAD on a class where there is no evidence the class was designed for CTAD (this warning would be suppressed by either an explicit deduction guide or by an attribute on the class template definition indicating that the constructors are designed to support CTAD) - 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) ... but I don't think we can justify warning on all CTAD. Have you considered the `clang-tidy` route? Given that it seems like your goal is to avoid accidental use of CTAD, an out-of-band (not part of regular compilations) check that you satisfy that goal would seem like it could be part of a solution. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54565/new/ https://reviews.llvm.org/D54565 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
