4 ms·

“ I’d be interested in a language that forces the use of Optional, Either instead of allowing for null, exceptions. Maybe Haskell does this?!” Well, Rust does.

• gowld 5y ago
  http://go/rs:std::ptr::null http://go/rs:std::ptr::null Function std::ptr::nullCopy pub const fn null<T>() -> *const T > Creates a null raw pointer.
  • paoda 5y ago
    Perhaps "Safe Rust" would be more apt (de-referencing any pointer is unsafe), though I think it's quite fine and well accepted to refer to "Safe Rust" as just "Rust". Of course, the null pointer can still exist in Safe Rust, but since you can't de-reference it I think it's fine to say Safe Rust is "close enough" to count.
  • steinuil 5y ago
    You can only dereference raw pointers from within an unsafe block so they're only useful inside unsafe blocks. IMO Unsafe Rust != Rust, unsafe is an extension to the language that is clearly separated from safe code, and using it essentially means voiding Rust's safety contract.
    • dgellow 5y ago
      Not that you're incorrect but to be even more precise, and for the readers who do not know about Rust, I would say "voiding *parts* of Rust's safety contract". Citing the documentation: > To switch to unsafe Rust, use the unsafe keyword and then start a new block that holds the unsafe code. You can take five actions in unsafe Rust, called unsafe superpowers, that you can’t in safe Rust. [...]: > - Dereference a raw pointer > - Call an unsafe function or method > - Access or modify a mutable static variable > - Implement an unsafe trait > - Access fields of unions > It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#unsafe-superpowers https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#unsa...
      • steveklabnik 5y ago
        I’m not even sure that captures it. You must not void the safety contract in unsafe Rust. The distinction is that with unsafe, you must manually uphold the safety contract.
        • dgellow 5y ago
          Ah yes, you’re right that I missed that part. The contract isn’t voided by using unsafe, what changes is that responsibility of enforcing the contract is moved to the developer instead of the compiler.
  • phpnode 5y ago
    You can only dereference this pointer if you work at Google!
    • pwdisswordfish9 5y ago
      Wait, there are non-Googlers here? Who let them in?
  • cbarrick 5y ago
    https://doc.rust-lang.org/std/ptr/fn.null.html https://doc.rust-lang.org/std/ptr/fn.null.html
  • lowbloodsugar 5y ago
    Once had a problem where customers complained about an app keep crashing and losing minutes or hours of work. Boiled down to a "null reference" in C++. Programmer responsible argued till blue in the face that his code could not have a bug because references (&) cannot be null. Of course they can. Rust, at least, requires that this happens in unsafe code, but for sure, a bug in unsafe code can lead to null references. We are doing noobs a disservice if we claim otherwise.
    • nybble41 5y ago
      > Programmer responsible argued till blue in the face that his code could not have a bug because references (&) cannot be null. Of course they can. It's undefined behavior merely to create a null reference in C++, whether or not it's used. Of course that doesn't mean you can't do it anyway ("int * p = NULL; int &x = * p;") but the bug would be in the code that created the null reference, not the code that used it, just as in Rust the bug would be in the unsafe code which created the null reference—Safe Rust code is allowed to assume that this situation will never occur. (One side effect of this rule is that the compiler is allowed to assume that "&x == NULL" will always be false for any reference "x", so even if you attempt to check for a null reference the check can be optimized out.)
      • lowbloodsugar 5y ago
        It was his code the created the null reference. He converted a null pointer into a reference. But doesn't matter: when presented with the evidence of a null reference, it would have been straightforward to diagnose the problem. And after repeated blustering and denials from him, that's what I had to do to get the bug fixed. We do a disservice if we tell people that references (in either language) cannot be null. They can be null, and that would be a bug in some other code - so follow the trail to find where.
• chriswarbo 5y ago
  Haskell doesn't have null, so Optional is the usual alternative (actually called "Maybe" in Haskell, but it's the same thing) Haskell values can throw exceptions (e.g. for division-by-zero, etc.); but catching them (and therefore branching on them) is an IO effect. That sort of exception is treated like an unfortunate necessity in Haskell; and user code tends to use a more structured, well-typed approach like Either (there are a few alternatives floating around in common libraries)
• jade-cat 5y ago
  Zig does as well. Looks like "null needs some abstraction, and exceptions are way too complex" is the current consensus, at least in some fields.