4 ms·
Maybe we should automatically exclude indexing, but it's telling that current crates like no-panic do not to that (instead they check if the compiler optimizes
by afdbcreid 2mo ago
Maybe we should automatically exclude indexing, but it's telling that current crates like no-panic do not to that (instead they check if the compiler optimizes out the panic, which accepts more cases but is not reliable and understandably not something a language feature can do).
Should indexing an array with a constant be marked? What is considered to be a constant? Those are complicated questions.
If you do not want genericity nor complicated handling, you can already get yourself covered, pretty much. Clippy has lints for panicking language operations/basic std functions, and it should be possible to write a linter that automatically infers if a function can panic.
- ameliaquining 2mo agono-panic relies on a linker hack because that's what's possible to do in stable Rust today; there's no API for adding an additional compiler pass that prohibits you from calling certain functions. Constants are well-defined in Rust; panicking operations like array indexing would be allowed within no-panic functions in const contexts (https://doc.rust-lang.org/reference/const_eval.html#const-context https://doc.rust-lang.org/reference/const_eval.html#const-co...), but not otherwise. There's a difference between genericity over no-panicness (which I argue is not needed for an MVP) and allowing otherwise generic functions to be no-panic (which I do think is required). I don't think a linter can do the latter, because it would need to integrate with the trait system (e.g., you would need a NoPanicDrop trait and possibly NoPanicFn(|Mut|Once) traits).