What exactly is gradual about the question: "Can this program panic?". Either you are optimistic and allow any unproveable panics through and now you program will panic in practice. Or you are pessimistic and basically disallow any practical program.

There are a lot of cases where a gradual approach works well. But something so fundamental and important like "Can this program panic?" is not one of those cases.

I was addressing your odd fixation on not being able to prevent an infinite loop. That's not a real downside. We can still make progress in many other areas in the meantime.

It's not about about being able to prevent an infinite loop. It's about being able to say this program really doesn't panic. Which is a very important property. For example the Linux Kernel requires Rust code to not panic. There was a lot of work done to ensure this was at all possible. And it wasn't to try and statically assert whether a piece of code panics. It was just disallow panics outright. Do you think these compiler developers just took that route because it's fun? Or because they are "oddly fixated on the halting problem"?

I don't know why you are so combative and immediately used the opportunity to reframe what I said above into attacking a good reasonable problem that we would all like eliminated (the halting problem) but I'll ask you to stop because that's not discussing in good faith; you seem to be on the lookout to attack someone and I am seriously not interested in that.

--

Having said that: being able to disable / remove `.unwrap` and co. with a compiler flag -- as you seem to imply is the case in the Linux kernel branch of Rust -- would prove hugely beneficial to no small amount of library and app developers.

And guaranteeing no panics isn't that hard. Sure the POSIX standard and Linux in particular are vague in many places but I think it's fairly reasonable to be able to guarantee that a program that doesn't use filesystem or network can never panic just through dependency analysis (e.g. no API is used that can propagate a panic from the kernel).

How useful would that program be is another discussion entirely though (quite an amusing one at that).

My point was and remains that not being able to detect infinite loops is not indicative of the ability to prove that panics [due to system / kernel API carrying them over to you or just straight up blowing up your program] will not occur. And you seem to claim the opposite?