Sorry, I meant that any function that was noreturn could be inferred to take up to forever to return (since it always takes forever to return, since it never returns). Then, any function that calls such a function (in a non-DCEed position) can be inferred to also take up to forever to return (even though it might take less than that), because some possible code path through it (it's up to X amount of time to return) takes forever due calling a function that takes forever.
* Rust doesn't infer function types (on purpose)
* like const (or Copy), the removal of the flag is a breaking change, so it should not happen implicitly
So functions would necessarily have to be explicitly marked as e.g. `convergent` or whatever. And while callers of `!`-functions would be easy to check for, I don't think rustc is currently smart enough to infer the totality loops in general.
> I don't think rustc is currently smart enough to infer the totality loops in general.
Well, yes; we're necessarily talking about changes to the language (or, equivalently, possible different languages).
> while callers of `!`-functions would be easy to check for, [other problems wouldn't]
That was my point, thanks: "when trying to save your crucial data to disk, in real-time code where panicking would maybe kill someone in the real world, etc", checking for the easy-to-check-for problems doesn't actually suffice to prevent disasters.
Sure. It is also by far the largest risk you face, so would solve a good 4 or 5 nines if the issue.
> And really, noreturn ought to be enough to infer that on its own.
noreturn only works for functions which never return. Most panicking functions do return, just not all the time.