To quote my comment from #17944

warn-unreachable is nice but form my experience often not completely accurate, unfortunately. It's fine to use with type: ignore[unreachable] but I'm not sure it's ready for --strict mode just yet.

I was shocked and dismayed to learn in #18386 that --warn-unreachable is not implied by --strict. @davidhalter said:

A lot of people probably think "I'm running --strict, there's nothing else important to enable".

That certainly describes me, and I'm sure many others.

It is obvious that there should be a flag to enable all checks. What that flag is named doesn't matter. There are two ways to do this:

1. The existing --strict flag is modified to enable all checks. A new flag --somewhat-strict is introduced maintaining the current somewhat-strict behavior of --strict.

2. The existing somewhat-strict --strict flag is maintained as-is. A new flag --strict-for-real is introduced that is strict for real, enabling all checks.

Again, the name doesn't matter. But there should be a flag that enables all checks, and the current --strict flag is not that.

As far as whether --warn-unreachable is accurate, I checked out the warnings for Pylint shown in #17944. They all look legit to me, definitely issues that ought to be addressed.

It is obvious that there should be a flag to enable all checks.

No, it is not: #2376. Also related: #7767.

Moreover, if we agree with the following --strict definition—

mostly the set of checks needed to ensure that you do not have any type unsoundness without an explicit circumvention of the type system, like type ignore, explicit use of Any or cast

—then --warn-unreachable is a bit out of the scope because it is not about "type unsoundness".

To be clear: I'm +1 on adding --warn-unreachable to --strict if (when) it will be accurate. I'm -1 on inventing "stricter than strict" of any kind because it is inevitably opinionated.

To be clear: I'm +1 on adding --warn-unreachable to --strict if (when) it will be accurate. I'm -1 on inventing "stricter than strict" of any kind because it is inevitably opinionated.

I think such a flag would really be helpful. I'm not sure I would enable it in my projects, but it would be interesting for checking once in a while. C rrently there are a lot of flags that are useful and almost nobody has them enabled. For example did you know --enable-error-code unused-awaitable, --enable-error-code ignore-without-code, --enable-error-code=mutable-override, --enable-error-code unimported-reveal or --enable-error-code truthy-bool? These are all useful error codes that I would enable by default in my projects and as far as I know they are not enabled in --strict. There are of course error codes that are more debable like redundant-self, redundant-expr or possibly-undefined.

But I'd rather have a flag that enables all of them, so I can turn them off if they are annoying. But at the moment I'm pretty sure almost nobody has enabled truthy-bool, because very few people know about its existence.

If people are struggling with --strict, they most likely have tried to add it to an existing codebase, but if you start fresh it really feels different. I personally like that Mypy's has implemented a lot of checks that might not be practical in old code bases > 20kLoC.

My favorite solution for this would probably be to add most of these to --strict in Mypy 2.0. People can still remove error codes manually (just add a short migration guide). Otherwise we could add a --really-strict that also includes --extra-checks or to just add the error codes I mentioned to --extra-checks.

I am in favor of enabling --warn-unreachable in --strict in Mypy, based on my experience with it, which has never had any false positives — but if an investigation like #17944 reveals too many false positives, then let those be fixed first, I suppose...

I am in favor of adding --warn-unreachable to --strict as late as 2.0 if need be. However, the documentation of --strict states:

Note: the exact list of flags enabled by running :option:--strict may change over time.

I interpret this to mean that adding --warn-unreachable to --strict does not need to wait for a major version change. It can be done immediately, on a minor version change. (Contrast with enabling it by default for unadorned runs of mypy, which would presumably call for a major version increment.)

Which means that this issue could be done instead: #11223

P.S.: On the generalized topic of making --strict even stricter: I support making --strict as strict as possible; that's what it's for, after all! I have too many thoughts along these lines to go into them exhaustively here.