AaronBallman wrote:
> Wait, _on by default_?
>
> Perhaps I'm out of line with current thinking here, but IMO, on-by-default
> should only diagnose things which are likely to be harmful -- NOT just a
> style or inefficiency issue, which seems to be all this is diagnosing. That
> LLVM's style conflicts with it also seems like a good indication that it
> should not be an on by default warning.
>
> I'd actually say it belongs in `-Wextra` -- not even `-Wall`.
I think this one is on the fence. Considering code like:
```
struct S final {
// .. lots of code that hides the declaration of `struct S final`
virtual void func(); // What was intended here?
};
```
This isn't harmful in the sense of finding a correctness issue because,
presumably, something elsewhere tries to derive from that class and gets an
error. And in the absence of a derived class, there's no semantic issues with
the code.
However, it is still mildly harmful if the person writing this code misses the
`final` on the class and commits the code to a library for others to use later.
The person writing the code may have no idea they introduced the bug, the
person consuming the code may have no easy way to fix the header, so alerting
the programmer when they're writing the code that something isn't right can be
useful.
https://github.com/llvm/llvm-project/pull/133265
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
