More algebraic effects being retrofitted onto Rust.
And as a language feature, not as a library.
Rust project goals: Immobile types and guaranteed destructors
111–112 of 112 posts
Re: Rust project goals: Immobile types and guaranteed destructors
#112Earlier quoted context omitted.
The problem with the trivial implementation is that it's barely useful. You cannot use indexing, for example. Not to mention it's still not easy: to have any usefulness, there will need to be a way to be generic over it (similar to keyword generics), and that's far from trivial.
Well, yeah, I would not expect indexing (on the standard library types) to be usable within a no-panic function, because panicking on out-of-range inputs is what those operations do. Admittedly, probably lots of people would initially think "oh, being sure never to panic sounds useful", look into it more, realize what's actually involved, and decide "never mind, I'll stick with the risk of panicking" (which is the co…
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.