[estebank]

There's a difference between code that used to compile no longer compiling because of an incorrect lint, and code that was never accepted. Rust is restrictive and gets less so over time. C and C++ need to become more restrictive over time, but that's a more traumatic direction.

[arinlen]

> Rust is restrictive and gets less so over time. C and C++ need to become more restrictive over time, but that's a more traumatic direction.

I don't agree at all with your comment, and I find that sort of opinion miopic and not grounded on real-world software projects.

I 've worked on a fair share of legacy projects which were ported to the latest and greatest projects, including a couple of nightmare JavaScript ones. The very first thing we did was onboard onto static code analysis tools and source code formatters.

Once we enabled them we were faced with a big wall of red text dumps. With time that wall shrinked until there was no more red, and from thereon things stuck that way.

There was no trauma, only a kaizen approach to errors being flagged.

The whole C++ world already does this for decades, whether it's for compiler warnings, static code analysis, memory checkers, fuzzers, etc. What exactly leads you to believe this is traumatic?

[dataflow]

What you're actually arguing seems to be "why I like Rust more than C++", not arguing why "clang-tidy has false positives, and thus the comparison isn't apples to apples then".

Clearly the positives can be just as false in Rust as in C++. Your actual objection is that anyone arguing that any feature of Clang can measure up to the corresponding feature of Rust at present is automatically disqualified from making that argument because... Clang's past "taints" its present? Like an original sin of sorts, but in programming? ("Apple" forbidden against comparison?)

[ufmace]

I don't think it's about being tainted. It's that there's a bunch of C++ code out there already in Production in a ton of places that doesn't pass those checks, and may or may not actually be safe. It would be a ton of work that may not produce any end-user value for any C++ project to switch over to that.

Meanwhile, Rust has always had those checks, so there can't be any Rust code in Production that doesn't pass them that would be painful to switch over.

[estebank]

It's not about an original sin, it's about the practicalities of changing the default behaviour without pissing off your users.

[dataflow]

Sure, but again, that's an argument for why you dislike C++, not an argument for why false positives in that Clang-Tidy check somehow disqualify it from being compared to the corresponding checks in Rust, especially when they both have false positives.