Use case: As an software engineer, I need to be able to sell rust as a suitable safety critical language to our safety engineers

[ah801]

For example, given a IEC 61508 SIL-1 project:
If this were C++ I would state that we would be compliant with MISRA C++ 2008 or MISRA C++ 2023 , and those rules would be enforced by xyz static analyser in the build and CI chain, using a certified checker against those rules.
This is a straight sell-off to a safety team in terms of partial compliance to 61508.

In order to do the same for rust, I need a set of coding guidelines/rules that do the same job. I need to prove to a safety engineer that we are following a certified set against 61508 (and would be enforced by the build and CI).

Whether this is multiple documents or 1 document (preferred) it does not matter, but we must have an agreed on and certified standard that industry can work with.

[darkwisebear]

I also see that as a necessity and I see two ways how this can be achieved:

1. We find a suitable already-existing document that covers all safety aspects where we then add numbered rules in between the explanations.
2. We start a new document (mdbook?) that contains the ruleset plus links to explanatory documents.

The existing documents that I know of are:

• Unsafe Code Guidelines
• Learn Unsafe Rust
• The Nomicon

These resources only cover the unsafe part of Rust. However, this is not the complete picture as there are other aspects that we need to also cover with coding guidelines. If there aren't any other documents I missed, I'd suggest a new document that contains the complete ruleset plus at least one additional document which covers the explanatory part of the (in Rust terms) safe aspects that still require attention from these guidelines.

What do you guys think?

[PLeVasseur]

I like how this issue focuses in on a useful deliverable for the safety-critical domain.

Are you familiar with SAE JA1020, produced by the SAfEr Rust Task Force? It's still in draft, but I think it could answer some of these questions. When approved, I think it could be worthwhile to have a group of folks from the subcommittee read through it and report back to the group for sort of "coverage of this issue".

What do you think?

[darkwisebear]

I do know of that activity; however, I haven't had a chance to see that document yet. And this is acually also my main concern: It feels pretty "closed" at the moment, and that doesn't really match with how Rust is developed and evolves within the community: As an open and transparent effort, which is quite the opposite to closed consortiums where you need to "buy in" in order to be allowed to contribute.

I'd be happy if the opposite is true, though, and the document is released to the public, the community can contribute and it's also open for usage, at least non-commercially (Don't get me wrong, I do understand that commercial use is a totally different story!). In that case I'd absolutely see this as a good candidate.