3 ms·

They are exactly the same practices that Rust has built-in into the language, so I'm not sure what you're hinting at.

sanxiyn 5y ago
In theory, C++ programs use std::optional, just as Rust programs use std::option. In practice, such C++ programs are extremely rare, whereas such Rust programs are majority.
- nicoburns 5y ago
  There's an even clearer example here: dereferencing a C++ std::optional is undefined behaviour. Dereferencing a Rust std::Option is a compile time error.
  - pjmlp 5y ago
    In theory, in practice when using debug libraries, undefined becomes defined as a runtime check that will lead to an assertion error, or a static analyser failure. https://godbolt.org/z/re51ensMe https://godbolt.org/z/re51ensMe terminate called after throwing an instance of 'std::bad_optional_access' what(): bad optional access Naturally not everyone goes by adopting best practices, so there is that.
Quekid5 5y ago
They're saying that the Rust compiler will reliably enforce these things... and that it's completely trivial to surface any cases where the programmer thinks that they are smarter than the compiler, e.g. for extra code review, outright rejection, etc.
- mgaunard 5y ago
  no, he's saying the C++ best practices are too convoluted, (implying the Rust ones aren't), when they're essentially the same, just enforced differently.
  - Quekid5 5y ago
    Read the post in the context of what it's replying to.
rcxdude 5y ago
Rust has semantics which are designed to allow those best practices to be watertight and enforced by the compiler. C++ has semantics which are designed to fit around many years of backwards compatibility with unsafe practices. Attempts to make static analysis for C++ which mirror rust's borrow checker have thus far failed. There is not an automatically enforcable set of rules for C++ in any version which give you the same safety guarantees at rust (and the non-automatically enforcable set of rules is not followable by humans in practice, since we keep getting memory safety bugs in C++ code).

In theory, C++ programs use std::optional, just as Rust programs use std::option. In practice, such C++ programs are extremely rare, whereas such Rust programs are majority.

nicoburns 5y ago
There's an even clearer example here: dereferencing a C++ std::optional is undefined behaviour. Dereferencing a Rust std::Option is a compile time error.
- pjmlp 5y ago
  In theory, in practice when using debug libraries, undefined becomes defined as a runtime check that will lead to an assertion error, or a static analyser failure. https://godbolt.org/z/re51ensMe https://godbolt.org/z/re51ensMe terminate called after throwing an instance of 'std::bad_optional_access' what(): bad optional access Naturally not everyone goes by adopting best practices, so there is that.

Quekid5 5y ago

They're saying that the Rust compiler will reliably enforce these things... and that it's completely trivial to surface any cases where the programmer thinks that they are smarter than the compiler, e.g. for extra code review, outright rejection, etc.

mgaunard 5y ago
no, he's saying the C++ best practices are too convoluted, (implying the Rust ones aren't), when they're essentially the same, just enforced differently.
- Quekid5 5y ago
  Read the post in the context of what it's replying to.

rcxdude 5y ago

Rust has semantics which are designed to allow those best practices to be watertight and enforced by the compiler. C++ has semantics which are designed to fit around many years of backwards compatibility with unsafe practices. Attempts to make static analysis for C++ which mirror rust's borrow checker have thus far failed. There is not an automatically enforcable set of rules for C++ in any version which give you the same safety guarantees at rust (and the non-automatically enforcable set of rules is not followable by humans in practice, since we keep getting memory safety bugs in C++ code).