[GolDDranks]

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.

[hmry]

I 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]

> 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]

Here's a semi-recent link (~a year ago) by one of the leaders of this initiative: https://blog.yoshuawuyts.com/extending-rusts-effect-system/

[noxer]

Normal rust can already do this. For example #[no_panic] attribute is implemented in https://github.com/dtolnay/no-panic crate.

[GolDDranks]

Via an unreliable, linker-based hack.

[rowanG077]

On 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.