Out of curiosity, is there some reason it would be harder than I'm imagining? It seems like a fairly straightforward type-system feature. (I.e., it would be a lot of work, but only because any significant new language feature is a lot of work.)
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 correct decision for almost all software). But there'd still be use cases for no-panic.
If this is the "trivial" implementation, then I'm not sure what a "nontrivial" implementation would look like, unless it means adding a proof-tactics language to Rust to allow statically checked proofs of arbitrary program properties. Which would be really cool and all kinds of useful, but which I think everyone realizes would be a gargantuan project even to design, let alone implement.
Genericity is not strictly required for no-panic to be useful (lots of type-system features still don't have it), but yes, it would be very nice to have. (Though one might hope that, once they figure out genericity for one keyword (probably const), that'd make it easier to add for others.)
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.
no-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.
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).
