4 ms·

The discussions about a lack of specification are, I think, the largest and most-relevant. Someone in an earlier discussion mentioned the Rust Reference [1], bu

The discussions about a lack of specification are, I think, the largest and most-relevant. Someone in an earlier discussion mentioned the Rust Reference [1], but it is not sufficient: in particular, many portions of the memory model, calling conventions, and borrow-checking enforcement are left unspecified. Rust's guarantees are built on these, and they are currently defined by the current rustc implementation. Until a complete and detailed standard is published, Rust will not have a stable AI, and cannot enjoy multiple implementations (which inhibits its portability). Even the bit about Cargo stems from this: without a specification, Cargo's implementation is the de facto explanation for to properly link external, compiled libraries against rust binaries. As Rust matures, I anticipate many of these things will stop being the case---and I really hope someone gets around to writing a different Rust compiler, using pattern-matched ASTS like you would in OCaml, instead of the current, visitor-based solution. 1. https://doc.rust-lang.org/1.0.0/reference.html https://doc.rust-lang.org/1.0.0/reference.html

lights0123 6y ago
Note that you linked to the Rust Reference from 2015: the living version lives at https://doc.rust-lang.org/reference/ https://doc.rust-lang.org/reference/.
the8472 6y ago
> calling conventions Afaik that's intentionally unspecified/implementation-specific so that the language can evolve. The C ABI is the de-facto interoperability layer. > the memory model According to the rustonomicon they're leaning entirely on the C++20 memory model at the moment.
steveklabnik 6y ago
> Until a complete and detailed standard is published, Rust will not have a stable AI, and cannot enjoy multiple implementations (which inhibits its portability). This is not really true; we already have one alternative implementation that's good enough to compile the compiler, though it is not complete yet. Also, the gcc folks are interested in getting Rust in, and a formal specification is not a roadblock for them. > Even the bit about Cargo stems from this: without a specification, Cargo's implementation is the de facto explanation for to properly link external, compiled libraries against rust binaries. This is not true; this interface to the compiler is stable.
- discardable_dan 6y ago
  > we already have one alternative implementation that's good enough to compile the compiler That's really interesting! Can you link it?
  - steveklabnik 6y ago
    https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
jcranmer 6y ago
While I do think the lack of a specification is problematic, I don't think it's quite the dealbreaker it's presented here as. Most programmers don't write ISO C; they write GCC/Clang/MSVC C. This is especially true in the systems programming domain. And these variants are frequently poorly-specified, if indeed they are at all. Start using __attribute__ (or __declspec), inline assembly, computed goto, etc., and you find that your program isn't well-specified. Implementation-defined behavior is also supposed to have its behavior documented by the compiler, but adherence to this rule is spotty (clang is the most notorious violator here). And the after-effects of these changes aren't localized: the semantics of __builtin_nontemporal in LLVM imply a change in the specification of atomic fences [1], not that it's documented anywhere in LLVM. The lack of a specification tends to not be a problem in practice because (and again, especially so for systems programmers) C tends to be viewed as a "portable assembly," and these extensions are mostly gateways for picking specific, more specialized instructions--which are less amenable to optimization. But the main value of the specification is to nail down what can and cannot be optimized, and if you're a person like me who loves pushing the margins of the specification, you'll really notice how desperately needed better specification of these extensions are, even in the C domain. [1] If you're wondering, LLVM treats the semantics of fences as adhering only to "normal" memory operations. MOVNT, the nontemporal operator in x86, is equivalent to a relaxed store, so you need to do a release fence (SFENCE) to guarantee visibility. However, x86 is TSO, so all regular stores effectively have a SFENCE following them, so release fences compile to nothing instead of SFENCE.
GlitchMr 6y ago
> calling conventions Rust intentionally doesn't have stable ABI. Having a specification wouldn't change that. C++ does have a stable ABI, and pays a cost due to that - for instance `unordered_map` is 3 times slower than it needs to be (the implementation cannot be improved specifically due to having a stable ABI). Use C ABI if you need components compiled using different rustc version to interoperate.

lights0123 6y ago

Note that you linked to the Rust Reference from 2015: the living version lives at https://doc.rust-lang.org/reference/ https://doc.rust-lang.org/reference/.

the8472 6y ago

> calling conventions Afaik that's intentionally unspecified/implementation-specific so that the language can evolve. The C ABI is the de-facto interoperability layer. > the memory model According to the rustonomicon they're leaning entirely on the C++20 memory model at the moment.

steveklabnik 6y ago

> Until a complete and detailed standard is published, Rust will not have a stable AI, and cannot enjoy multiple implementations (which inhibits its portability). This is not really true; we already have one alternative implementation that's good enough to compile the compiler, though it is not complete yet. Also, the gcc folks are interested in getting Rust in, and a formal specification is not a roadblock for them. > Even the bit about Cargo stems from this: without a specification, Cargo's implementation is the de facto explanation for to properly link external, compiled libraries against rust binaries. This is not true; this interface to the compiler is stable.

discardable_dan 6y ago
> we already have one alternative implementation that's good enough to compile the compiler That's really interesting! Can you link it?
- steveklabnik 6y ago
  https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc

jcranmer 6y ago

While I do think the lack of a specification is problematic, I don't think it's quite the dealbreaker it's presented here as. Most programmers don't write ISO C; they write GCC/Clang/MSVC C. This is especially true in the systems programming domain. And these variants are frequently poorly-specified, if indeed they are at all. Start using __attribute__ (or __declspec), inline assembly, computed goto, etc., and you find that your program isn't well-specified. Implementation-defined behavior is also supposed to have its behavior documented by the compiler, but adherence to this rule is spotty (clang is the most notorious violator here). And the after-effects of these changes aren't localized: the semantics of __builtin_nontemporal in LLVM imply a change in the specification of atomic fences [1], not that it's documented anywhere in LLVM. The lack of a specification tends to not be a problem in practice because (and again, especially so for systems programmers) C tends to be viewed as a "portable assembly," and these extensions are mostly gateways for picking specific, more specialized instructions--which are less amenable to optimization. But the main value of the specification is to nail down what can and cannot be optimized, and if you're a person like me who loves pushing the margins of the specification, you'll really notice how desperately needed better specification of these extensions are, even in the C domain. [1] If you're wondering, LLVM treats the semantics of fences as adhering only to "normal" memory operations. MOVNT, the nontemporal operator in x86, is equivalent to a relaxed store, so you need to do a release fence (SFENCE) to guarantee visibility. However, x86 is TSO, so all regular stores effectively have a SFENCE following them, so release fences compile to nothing instead of SFENCE.

GlitchMr 6y ago

> calling conventions Rust intentionally doesn't have stable ABI. Having a specification wouldn't change that. C++ does have a stable ABI, and pays a cost due to that - for instance `unordered_map` is 3 times slower than it needs to be (the implementation cannot be improved specifically due to having a stable ABI). Use C ABI if you need components compiled using different rustc version to interoperate.