4 ms·
> noreturn only works for functions which never return. Most panicking functions do return, just not all the time. Sorry, I meant that any function that was no
by a1369209993 6y ago
> noreturn only works for functions which never return. Most panicking functions do return, just not all the time.
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.
- masklinn 6y agoThat is true, although I don't know how helpful that is aside from checking that the annotation is not broken? Much like `const`, the annotation would have to be opt-in either way: * 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.
- a1369209993 6y ago> Rust doesn't infer function types (on purpose) > 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.