3 ms·

In the cases where the problem is actually panicing (ie, a non-total function) rather than your choice of core-dumping code, lack of panic-ability is strictly i

by a1369209993 6y ago

In the cases where the problem is actually panicing (ie, a non-total function) rather than your choice of core-dumping code, lack of panic-ability is strictly insufficient - `while(1){/*busy-loop*/}` is exactly as bad as `panic();`, and what you actually need is not "must never panic", it's "must make forward progress within some (not necessarily rigorously defined but) small amount of time". That doesn't have anything to do with panic besides that `panic` would be declared as `fn(string)->noreturn[takes_upto: (infinity * seconds)];`, rather than just `fn(string)->noreturn`. (And really, noreturn ought to be enough to infer that on its own.)

masklinn 6y ago
> lack of panic-ability is strictly insufficient 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.
- 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 ago
    That 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.

masklinn 6y ago

> lack of panic-ability is strictly insufficient 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.

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 ago
  That 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.