Do you have some examples of MISRA rules you think would need "a very specific subset of Rust" rather than for example, #![forbid(unused)] to obey MISRA's rejection of unused stuff ?

A lot of MISRA is concerned with defects in C - or in its standard library and the usual C idiom - that simply aren't present in Rust and so need zero work to eliminate. For example MISRA forbids trigraphs. Rust of course doesn't have trigraphs.

A bunch more is stuff Rust warns about, that you can tell it to outright forbid, such as #![forbid(unused)] to obey various MISRA rules about using things.

In a few places MISRA obliges you to either squint hard at the rules, or agree that it is contradictory and you must grant yourself a deviation from the rules, while Rust just solves the underlying conundrum entirely. For example MISRA wants exhaustive matching, it has rules for switches to try to achieve that but in the process it introduces dead code it has already forbidden. Rust only has exhaustive matching anyway - if your match compiles it was exhaustive - thus there is no need to introduce dead code "just in case".

I think you're understimating how far MISRA goes.

Rules about identifiers for example, no shadowing, explicit typing only, no unused declarations etc.

Rust might get the big stuff but MISRA is adhered to exactly in contexts where things that would be "nitpicky" or over-opinionated for a general use language improve safety. Pure Rust would never be a replacement for that without additional static analysis.

I asked you for some example rules, and you provided some

> Rules about identifiers for example, no shadowing, explicit typing only, no unused declarations etc.

#![forbid(clippy::shadow_reuse)]

... is a Clippy lint denying shadowing to re-use variables. There are a couple more Clippy lints to deny other types of shadowing. Whether all, some or none of these are actually a good idea depends whether your goal is to just do what MISRA says no matter, or actually write better code.

#![forbid(clippy::default_numeric_fallback)]

... is a lint requiring that you specifically say what type numbers are rather than relying on the inference to conclude they're i32 if there's no reason they should be anything else.

#![forbid(unused)]

... I already mentioned, it outright forbids your code from not using things, function parameters, variables, whatever.

If anything I'd say the contrary is true, people overestimate what MISRA achieves, big chunks of it could be summarised as "Don't do things that are obviously a terrible idea". I suppose this might help to rein in some "Real programmer" types at an embedded systems firm using C by giving their manager a tool that says e.g. no, actually redefining size_t is not a clever trick, but it means all those rules are entirely irrelevant for any modern language, not just Rust.

So you're saying for two of the three arbitrary rules I mentioned you need additional tooling for analysis... sure sounds like my initial point.

But that's not even the point.

> If anything I'd say the contrary is true, people overestimate what MISRA achieves, big chunks of it could be summarised as "Don't do things that are obviously a terrible idea".

This is exactly what I mean. You're missing the point of MISRA if you think that's an overestimation or just to make managers happy... MISRA is often for life or death, and it's not even going as far as the random ISO standards that end up applying on top of it in some domains. It might be "obviously terrible" stuff, but very excellent developers end up doing it anyways sometimes, that's just being human.

The ground work to even verify a Rust toolchain doesn't even exist, (the closest I could find is a WIP https://ferrous-systems.com/blog/sealed-rust-the-pitch/) so I'm guessing everyone forcing this is likely rolling their own setup of additional tools?

If you don't work on ABS controllers and you work at somewhere like Tesla where the bar for safety is a little lower in the name of using new shiny things, by all means use Rust. But I wouldn't do that in a million years. I simply don't buy that using established MISRA C tooling is less safe than rolling your own lint setup.

> So you're saying for two of the three arbitrary rules I mentioned you need additional tooling for analysis

Sure, if you consider Clippy "additional tooling" for Rust.

As I understand it, MISRA rules (those which are clearly decidable) are also not enforced by the compiler but instead require a separate toolchain, and not one that's supplied by default with your compiler either.

> But that's not even the point. > [...] MISRA is often for life or death

It's far from clear whether MIRSA is "life or death". Some MISRA rules correlate well to serious programming mistakes, most not so much, but they do pad the MISRA ruleset which is commercially important. There have been real studies about this, they don't come away with the conclusion you seem to expect.

> It might be "obviously terrible" stuff, but very excellent developers end up doing it anyways sometimes, that's just being human.

This is half true. There are things that are a bad idea, which are easy in C and so real people will do them, and a few of these are caught by MISRA rules. None of those things is easy (many aren't even possible) to do in modern languages. Or indeed, in Ada. MISRA is a band aid on a hand C programmers have put through a band saw. "Let's not use C" is a better fix than "Let's use MISRA".

I mentioned the value of assignment as an example, clearly assignment shouldn't have a value, it doesn't in Ada, and it doesn't in Rust, or Swift. When your hypothetical "just human" developer tries to use the value of an assignment in C that works but in these other languages it won't compile. Whereas in C we need MISRA rules to forbid this bad idea.

Let's try another one. MISRA forbids declaring variables in the body of a switch. You can't do anything similar in languages like Rust or Ada because it's crazy. Nobody does it in C either, but they could and so MISRA forbids it just in case. But once again, MISRA isn't adding any real value here (except to tool sellers) by telling people not to do things that aren't done.

I can't speak to any of the "random ISO standards". To the extent they're trying to force C into being a reasonable language to write safety critical software it seems like a waste of time to me. If they're mostly about Software Engineering then that doesn't lose applicability when you switch to a better language.