3 ms·
I think that for a guarantee as central as non-panicking, there ought to be eventually some kind of support in the core language. (Just throwing ideas here, bu
by GolDDranks 1y ago
I think that for a guarantee as central as non-panicking, there ought to be eventually some kind of support in the core language.
(Just throwing ideas here, but there could be `#[never_panic]` for simple cases where the compiler can clearly see that panic is not possible, or error otherwise, and `#[unsafe(never_panic)]` for more involved cases, that could be proven with 3rd party tools or by reasoning by the developer like normal unsafe blocks.)
For more complicated guarantees, it's harder to see if there's enough common ground for these tools to have some kind of common ground.
- deleted 1y ago[deleted]
- noxer 1y agoNormal rust can already do this. For example #[no_panic] attribute is implemented in https://github.com/dtolnay/no-panic https://github.com/dtolnay/no-panic crate.
- GolDDranks 1y agoVia an unreliable, linker-based hack.
- rowanG077 1y agoOn one hand you are right. On the other hand knowing it can't panic because the code is literally not there is a very strong guarantee.
- hmry 1y agoI think the current plan is to integrate never-panic into the upcoming effect system (formerly keyword generics), along with const and async. So all these function annotations can share the same behavior and syntax, and higher order functions can be generic over them (e.g. "iterator.map(f) is never-panic if f is never-panic" etc)
- nextaccountic 1y ago> effect system (formerly keyword generics) Any recent link about that? Specially one that calls it effect system rather than the old name keyword generics
- NobodyNada 1y agoHere's a semi-recent link (~a year ago) by one of the leaders of this initiative: https://blog.yoshuawuyts.com/extending-rusts-effect-system/ https://blog.yoshuawuyts.com/extending-rusts-effect-system/