There is a spectrum from specifying the desired outcome to specifying the exact algorithm. For example, Ferrocene Language Specification 7.4, Variables, simply says “A local variable shall be used only after it has been initialized through all reachable control flow paths”. Compare C# specification 9.4, Definite assignment, which goes on and on and on about the exact algorithm used.
This is an error, not a warning, so it needs to be specified. There is also a genuine ambiguity here about what is “reachable”. In Rust, body of “if false” is considered reachable, while in C# it is considered unreachable. Still, I am not sure whether C# style specification is called for here. Maybe a note clarifying that values of expressions are ignored is enough. Maybe this part of Ferrocene Language Specification is simply incomplete and they plan to specify the exact algorithm.
There’s a ton of flexibility here, which is why we clearly say that the FLS is only for our purposes, which is the qualification of a compiler. In a qualification, we need a requirements document describing the behaviour of a program - which for the purposes of programming languages is usually a spec. But here, it’s okay at places to be vague, because the main intent is to describe what tool users can rely on. It is, in it’s current form, not meant to build a second compiler with it.
The second thing is that it is currently in preview form - all important chapters, the structure and the tooling is there. It will be refined until the end of the year.
That being said, it is explicitly shared so that people can get feedback or inspiration from it.
The point of FLS is to be a spec matching a certain version of the Rust compiler that others can write compliant compilers against. It is providing a language spec (just one that is downstream from Rust itself.)
There is a spectrum from specifying the desired outcome to specifying the exact algorithm. For example, Ferrocene Language Specification 7.4, Variables, simply says “A local variable shall be used only after it has been initialized through all reachable control flow paths”. Compare C# specification 9.4, Definite assignment, which goes on and on and on about the exact algorithm used.
This is an error, not a warning, so it needs to be specified. There is also a genuine ambiguity here about what is “reachable”. In Rust, body of “if false” is considered reachable, while in C# it is considered unreachable. Still, I am not sure whether C# style specification is called for here. Maybe a note clarifying that values of expressions are ignored is enough. Maybe this part of Ferrocene Language Specification is simply incomplete and they plan to specify the exact algorithm.
There’s a ton of flexibility here, which is why we clearly say that the FLS is only for our purposes, which is the qualification of a compiler. In a qualification, we need a requirements document describing the behaviour of a program - which for the purposes of programming languages is usually a spec. But here, it’s okay at places to be vague, because the main intent is to describe what tool users can rely on. It is, in it’s current form, not meant to build a second compiler with it.
The second thing is that it is currently in preview form - all important chapters, the structure and the tooling is there. It will be refined until the end of the year.
That being said, it is explicitly shared so that people can get feedback or inspiration from it.
Oh, heck yeah. This will make Rust a lot more viable for embedded - “the compiler is the spec” is terrifying for anything life/property critical.
The compiler is still the authoritative spec. I guess the FLS is something more like a rationale or a summary?
The point of FLS is to be a spec matching a certain version of the Rust compiler that others can write compliant compilers against. It is providing a language spec (just one that is downstream from Rust itself.)
No, conformance between compiler implementations is explicitly out of scope. We created the FLS only because we need a document like that to qualify Ferrocene for the relevant safety-standards.
No, the point is to have something to perform verification against (“high assurance software”).