[IshKebab]

The problem isn't implicit things happening.

He's talking about this problem. Can this code panic?

    foo();

You can't easily answer that in Rust or Zig. In both cases you have to walk the entire call graph of the function (which could be arbitrarily large) and check for panics. It's not feasible to do by hand. The compiler could do it though.

[throwaw3y]

"Panic-free" labels are so difficult to ascribe without being misleading because temporal memory effects can cause panics. Pusher too much onto your stack because the function happened to be preceded by a ton of other stack allocations? Crash. Heap too full and malloc failed? Crash. These things can happen from user input, so labelling a function no_panic just because it doesn't do any unchecked indexing can dangerously mislead readers into thinking code can't crash when it can.

[zozbot234]

There's plenty of independent interest in properly bounding stack usage because this would open up new use cases in deep embedded and Rust-on-the-GPU. Basically, if you statically exclude unbounded stack use, you don't even need memory protection to implement guard pages (or similar) for your call stack usage, which Rust now requires. But this probably requires work on the LLVM side, not just on Rust itself.

Failable memory allocations are already needed for Rust-on-Linux, so that also has independent interest.

[OptionOfT]

What about doing something that Java does with the throws keyword? Would that make the checking easier?

[bigfishrunning]

I think that's exactly what's being asked for here (via the "panic effect" that the article refers to)

although, I think i'd prefer a "doesn't panic" effect just to keep backwards compatibility (allowing functions to panic by default)

[3836293648]

Or effect aliases. But given that it's strictly a syntactic transformation it seems like make the wrong default today, fix it in the next edition. (Editions come with tools to update syntax changes)

[mananaysiempre]

Something like that, except you probably also want to be able to express things like “whatever the callback I’m passed can throw, I can throw all of that and also FooException”. And correctly handle the cases when the callback can throw FooException itself, and when one of the potential exceptions is dependent on a type parameter, and you see how this becomes a whole thing when done properly. But it’s doable.