fls

Ferrous created a language specification. https://github.com/ferrocene/specification They do say any differences between it and upstream behavior or documentation is a defect in the spec, not upstream. So it isn't authoritative. Unless we all decide it is.

>> The spec does not define the software. The software is as the software does. Having or not having a spec doesn't protect from bugs - people do. >> What you're taking about is covering one's ass, not specification. They are related. In safety-critical software, bugs can cause people to die. Without a spec, no one will use Rust for safety critical software. It would be too risky and no company would accept that level of risk. For example if software that controls an airplane is written in Rust and an error occurs during flight, what happens? The software can't just panic and crash or the airplane might crash. The Ferrocene project (https://ferrous-systems.com/ferrocene/) is working on producing a safety-critical Rust specification (https://github.com/ferrocene/specification) because having a language specification matters for safety-c

>> Rust is defined by the implementation. Hopefully not for long: https://github.com/ferrocene/specification https://ferrous-systems.com/blog/the-ferrocene-language-spec... Hopefully Ferrocene can lead to Rust itself being standardized. To me, it seems inevitable that there will be multiple implementations of Rust, especially if Rust continues to be more widely adopted and used in new domains. I would also not be surprised if Rust were to adopt optional language extensions for specialized use cases, similar to Ada's language annexes: http://www.ada-auth.org/standards/22rm/html/RM-1-1-2.html Why? Because the Rust implementation you use for video game programming does not need all of the same features as the Rust implementation that you use for safety-critical embedded systems (for example: railroad control software).