It was mentioned that they need to operate with a subset of the language that cannot panic. (And also disabled automatic overflow in arithmetic). This seems fairly easy to achieve with flags and conditional compilation.
From an ecosystem point of view this creates a situation similar to
no-std today. Crates are tagged and documented as being
crates.io so that people can tell if they can be used in their context. It seems likely that we will eventually have crates being marked as
no-panic to indicate they they are
no-std and also compile without the need for code to support panicking. Obviously such crates can still be used by applications that don't care about such things.
This introduces a problem similar one that exists for
no-std crates today. It's easy to make a mistake and call a function which is not available and cause downstream crates' builds to fail.
The problem is that during development
panic, etc are available because they are needed for tests. Hence even if the code is made to accidently depend on them it will compile.
It would be extremely useful to have a way to fail a build of a crate which for example declares itself
no-std and ends up linking against
std and, assuming such an annotation is added, declares itself
no-panic but ends up linking against code to panic. This way rather than failing a downstream build after the crate has be published, the bug is caught early and the developer sees an error as soon as they type the offending line.