3 ms·

can you show me how rust does this? I'm genuinely curious. I've made a toy example to show how c++ checks for undefined behavior at compile time, I am unaware o

can you show me how rust does this? I'm genuinely curious. I've made a toy example to show how c++ checks for undefined behavior at compile time, I am unaware of rust being able to do the same without runtime costs (however small they may be, this is a toy example after all) https://godbolt.org/z/cT9bqz8z7 https://godbolt.org/z/cT9bqz8z7

elteto 2y ago
Compile time checked pattern matching: https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html
- macgyverismo 2y ago
  That matches the 'static_assert' portion of my sample code. The implied claim of the parent I replied to was that rust could do this even for runtime values, such as the one I am using in the main of my sample. In c++ it is the same function running both the compile time check and the unchecked runtime variant, so there is zero overhead at runtime. I can't possibly think of a way how rust would be able to make the same code in my sample safe without adding runtime checks. If I am mistaken here I sure would like to know.
  - School-Cotton 2y ago
    You’re correct. Rust can’t statically prove which enum variant is inhabited. You do need a runtime switch, the difference is (at least in safe code) it statically forces you to indeed do that runtime switch.
  - kaashif 2y ago
    You aren't mistaken. I should've written "runtime overhead" - my point is that there is no runtime performance penalty for getting rid of the UB in the Option API. An equivalent API with no UB is just strictly better.
deleted 2y ago
[deleted]
kaashif 2y ago
The point is that Option in Rust doesn't have undefined behavior in any case, even if the values aren't known at compile time. Exhaustiveness is always checked at compile time, unlike C++ where operator* offers an escape hatch where nothing is checked in non-constexpr contexts. "Make everything constexpr" isn't a real solution to UB, in the same way that "make all functions pure" isn't a solution for managing side effects. Not adding UB to your APIs, on the other hand, is a real solution.
- School-Cotton 2y ago
  You can actually implement the C++ behavior, if you want: unsafe fn super_unwrap<T>(x: Option<T>) -> T { match x { Some(val) => val, None => unreachable_unchecked!(), } } But defaults matter, and Rust certainly doesn’t make this kind of thing ergonomic (which is a correct decision on the Rust designers’ part).
  - kaashif 2y ago
    Yeah, absolutely. My point is that Option itself doesn't give you this API and to make an unsafe version, you have to explicitly write it. Including UB in easy to misuse places is totally unnecessary and a footgun which really does cause issues in real code.
    - School-Cotton 2y ago
      Yep, I agree completely. Just wanted to point out for completeness that rust can theoretically do the same thing as c++.
  - tialaramex 2y ago
    You don't have to write this, it already exists as the (unsafe of course) method Option::unwrap_unchecked Because all Rust's methods can be called as free functions, you can literally write Option::unwrap_unchecked for the same behaviour, or you can some_option.unwrap_unchecked() (in both cases you will need to be in unsafe context for this to be allowed and should write a SAFETY comment explaining why you're sure it's correct)

elteto 2y ago

Compile time checked pattern matching: https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html

macgyverismo 2y ago
That matches the 'static_assert' portion of my sample code. The implied claim of the parent I replied to was that rust could do this even for runtime values, such as the one I am using in the main of my sample. In c++ it is the same function running both the compile time check and the unchecked runtime variant, so there is zero overhead at runtime. I can't possibly think of a way how rust would be able to make the same code in my sample safe without adding runtime checks. If I am mistaken here I sure would like to know.
- School-Cotton 2y ago
  You’re correct. Rust can’t statically prove which enum variant is inhabited. You do need a runtime switch, the difference is (at least in safe code) it statically forces you to indeed do that runtime switch.
- kaashif 2y ago
  You aren't mistaken. I should've written "runtime overhead" - my point is that there is no runtime performance penalty for getting rid of the UB in the Option API. An equivalent API with no UB is just strictly better.

deleted 2y ago

[deleted]

kaashif 2y ago

The point is that Option in Rust doesn't have undefined behavior in any case, even if the values aren't known at compile time. Exhaustiveness is always checked at compile time, unlike C++ where operator* offers an escape hatch where nothing is checked in non-constexpr contexts. "Make everything constexpr" isn't a real solution to UB, in the same way that "make all functions pure" isn't a solution for managing side effects. Not adding UB to your APIs, on the other hand, is a real solution.

School-Cotton 2y ago
You can actually implement the C++ behavior, if you want: unsafe fn super_unwrap<T>(x: Option<T>) -> T { match x { Some(val) => val, None => unreachable_unchecked!(), } } But defaults matter, and Rust certainly doesn’t make this kind of thing ergonomic (which is a correct decision on the Rust designers’ part).
- kaashif 2y ago
  Yeah, absolutely. My point is that Option itself doesn't give you this API and to make an unsafe version, you have to explicitly write it. Including UB in easy to misuse places is totally unnecessary and a footgun which really does cause issues in real code.
  - School-Cotton 2y ago
    Yep, I agree completely. Just wanted to point out for completeness that rust can theoretically do the same thing as c++.
- tialaramex 2y ago
  You don't have to write this, it already exists as the (unsafe of course) method Option::unwrap_unchecked Because all Rust's methods can be called as free functions, you can literally write Option::unwrap_unchecked for the same behaviour, or you can some_option.unwrap_unchecked() (in both cases you will need to be in unsafe context for this to be allowed and should write a SAFETY comment explaining why you're sure it's correct)