It’s not because we have tested this program extensively on every C++ compiler, but because the language rules of C++ say so.
Debatable. Saying things in a prose specification doesn’t magically make them happen. Tests and reference models can though.
I also don’t really agree with the SIL requirements that languages need to have rigorous specifications to be safe. Clearly it’s better if they do, but would your rather fly on a rocket controlled by C code or Rust code?
IMO a specification would be really nice to have, but it main purpose is to tick a certification checkbox, which is why the only one that exists was written specifically for that purpose.
The specification does not make anything happen but it enables you to say “the implementation is wrong”. Of course, you can say that without a spec as well but what does “wrong” mean then? It just means you personally disagree with its behavior. When “wrong” means “inconsistent with the spec” everybody involved can work with more clarity and fewer assumptions. Wrong assumptions can kill people flying rockets.
you can say that without a spec as well but what does “wrong” mean then? It just means you personally disagree with its behavior.
Nope. Specs can have bugs. Here are the bugs in the C++ spec for example:
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html
As I said, specifications are useful and desirable, but the SIL’s dogmatic “no spec = unsafe” is clearly not based in reality.
In SIL world, the C++ issues would not be considered bugs but maybe change requests.
The SIL philosophy (as far as I know it from ASIL) is “unsafe unless convinced otherwise”. That seems like a good idea when the lifes of humans are on the line. Without a spec how would you argue that a system/product is safe?
(Aside: Software in itself cannot be safe or unsafe because without hardware it cannot do anything. Safety must be assessed holistically including hardware and humans.)
A specification is just another form of implementation that suffers from the very same problem you describe too.
Fair enough. In practice, we resolve it recursively with a higher level specs and at some point it is just “someone wants that”. In commercial software development (where SIL is used) that is a customer who pays for it or some executive.
Depends, if it’s my Rust code I’d rather get some Torvalds-Level C please
After reading LWN Kernel articles for a while now I would much rather have the Rust please. The C code base of the Linux kernel seems a total mess despite Torvalds having the final say on what is merged and what is not.
It’s not as if nothing is being done on GitHub we have both: rust-lang/spec which is being folded into rust-lang/reference.
I’m not sure why we don’t have an official spec, I assume that reference was originally for rustc in particular and might include some internal weirdness instead of being a proper spec. Kinda like how gcc has some internal magic that isn’t strictly to C spec.
I guess what happened was: spec for rustc -> developed rustc -> ferrocene developed from rustc spec -> “we don’t have a generic rust language spec”
I’m actually surprised there is no specification. It’s how I thought languages were written: spec first, implementation later. Do RFCs serve this purpose?
That requires a complete picture and all possible use cases from the start. Initially when a language is new and hardly used there are much to benefit from flexibility and trying new concepts. Then as the language matures, a more formal process is needed to ensure stability. There is a reason these discussions comes now, since rust is in a very stable phase.
There might also just not be a single spec because the information is spread out over RFCs instead of being collected in a central location.
Welcome to the real world. /s
