4 ms·

This comment is strongly confused about typechecking. > [1] https://github.com/Technolution/rustig https://github.com/Technolution/rustig That's a binary anal

This comment is strongly confused about typechecking. > [1] https://github.com/Technolution/rustig https://github.com/Technolution/rustig That's a binary analysis tool (for x86_64 only!). It is only approximate, and does not claim to be an accurate analysis like typechecks (such as the unsafe check) are: https://github.com/Technolution/rustig#limitations https://github.com/Technolution/rustig#limitations > All paths leading to panic! from one of those functions (whether actually used or not) will be reported. Crude binary analyses like these lack the critical efficiency and predictability properties of type checks: * Typechecks like the unsafe-check can be done on each module in isolation, using the code from that module and only the types (not the code) from any modules that it calls. This is the essential property that makes typechecking efficient enough to run on every compilation. * If each module separately passes the check, then a program using both of them passes the check. This is the essential property that makes typechecking predictable enough to produce useful error messages. This binary analysis tool operates on the whole program. Turning optimizations on and off will cause the tool to switch from reporting "ok" to reporting false positives. Pretending that a tool like this is a replacement for a typechecker amounts to grossly negligent software engineering. Panics are an ugly leftover from the bad old days before Rust had nice monad-like "?" syntax for Result<T,E> error-handling. It's time for unrestricted panic to sunset. The Rust community has waited too long to do this, which is why it will be painful. Waiting longer will only make it even more painful. > panics are catch-able False. Unwinding panics runs drop handlers; if one of these drop handlers itself panics, Rust just sort of throws its hands up in the air and aborts the process no matter what: > Given that a panic! will call drop() as it unwinds, any panic! in a drop() implementation will likely abort. https://doc.rust-lang.org/std/ops/trait.Drop.html#panics https://doc.rust-lang.org/std/ops/trait.Drop.html#panics The panic mess is full of nasty ill-defined edge cases like this. It's gotta go.

littlestymaar 6y ago
Panics are useful, because no-one wants to clutter their function signature with errors that are in fact invariant assertions. Granted, It's not elegant, but it does the job. Expressing potentially panicking functions in the typesystem (or an effect system) would add little benefit for most users, given that even the Linux kernel is likely to use panics (with the panic handler calling BUG) for things that represent broken invariants (array overflow, assert, etc) and it's not really possible to do because integer overflow have a different behavior depending on whether they are in debug or in release mode. Since it's a really niche use-case, it makes total sense to be an external tool. > > panics are catch-able > False. Unwinding panics runs drop handlers; if one of these drop handlers itself panics, You didn't really read my previous comment right? (emphasis mine, to give you some help) > panics are catch-able as long as you don't compile your binary with panic=abort setting (and as long as you don't panic in your panic handler itself (including in your types' destructor, which are called during stack unwinding))

littlestymaar 6y ago

Panics are useful, because no-one wants to clutter their function signature with errors that are in fact invariant assertions. Granted, It's not elegant, but it does the job. Expressing potentially panicking functions in the typesystem (or an effect system) would add little benefit for most users, given that even the Linux kernel is likely to use panics (with the panic handler calling BUG) for things that represent broken invariants (array overflow, assert, etc) and it's not really possible to do because integer overflow have a different behavior depending on whether they are in debug or in release mode. Since it's a really niche use-case, it makes total sense to be an external tool. > > panics are catch-able > False. Unwinding panics runs drop handlers; if one of these drop handlers itself panics, You didn't really read my previous comment right? (emphasis mine, to give you some help) > panics are catch-able as long as you don't compile your binary with panic=abort setting (and as long as you don't panic in your panic handler itself (including in your types' destructor, which are called during stack unwinding))