(But thanks, I overlooked T? conversions inside if.)
The whole idea of optional is to make not optional possible.
The billion dollar mistake is overblown?
I actually like the language support more, as it flows a lot better than the (flat)map chain you get in monadic style. Similar to async/await v.s. Future.
At any boundary where something might be null, you do the null check. If it's null, you do whatever logic is necessary right there and only right there. That might be to skip the computation, to use a default value, to get the value from somewhere else, to return an error, or whatever. If it's not null, you use the internal value and from then on every user can operate on a guarantee that it's not null.
> Tell me more about these unexplodable languages.
I don't think anyone else mentioned an entire language being unexplodable, just a pointer type.
Later on the thread you talk about `Option` in Rust, which is not what I think most people would consider a pointer type, but even if it is, it's certainly not the only one. I think GP was talking about the basic reference type (i.e. `&T`), which will not ever be null in safe code, so dereferencing it will not explode.
#[derive(Default)]
struct Foo {
…
}
struct Bar {
…
}
fn do_something(foo: Foo) -> Bar {
# do something with Foo and return a Bar
…
}
fn main() {
let opt_foo: Option<Foo> = None;
// panics
let foo: Foo = opt_foo.unwrap();
// panics, but with an error message of your choosing
let foo: Foo = opt_foo.expect("foo was supposed to be there");
// converts the Option (Some or None) to a Result (Ok or Err,
// where Err can contain an error type or message and then passed
// around or returned or whatever)
let foo: Result<Foo> = opt_foo.ok_or("foo was supposed to be there");
// replaces it with a value of your choosing if it's not there
let foo: Foo = opt_foo.unwrap_or(Foo { … });
// replaces it with the default value the type defines
let foo: Foo = opt_foo.unwrap_or_default();
// keeps it as `None`, or if it's actually something then
// replaces the internal contents with the result of the
// function call
let bar: Option<Bar> = opt_foo.map(do_something);
// does arbitrary logic in the match arm if foo is there
match opt_foo {
Some(foo) => { do something with foo },
None => { do something else },
}
}
The point is that you can't use the inner value without choosing a course of action if it happens to be none.
> > Sane languages have pointers which either can't be null or require you to check explicitly.
You cannot try to dereference a nullable pointer in safe Rust. It has got nothing to do with Optional (Some/None).
The comment that you -- with aloof disbelief -- replied to only talked about pointers. I don't know what point you think you are proving with these pithy replies. It sure does go above my head. :)
It may be surprising to learn that languages without implicitly-nullable types are real, but you should understand that none of these people would be trying to tell you about this if these languages simply exploded any time you used them the wrong way.
There is a difference between a type Pointer where `null` is an instance of that type and a type Box which only has valid (can be dereferenced) values. If the language has e.g. algebraic data types and pattern matching then Option(al)<Box> can be safely matched on and Box can be used in the branch (the pattern match arm) where Some(Box). Meanwhile in a language with Pointer and no flow analysis any dereference of Pointer could lead to some kind of "panic".
Say "unwrap()" all you want but the two approaches are clearly very different.
Yes, Rust options explode if you unwrap a None. But that's explicitly what `unwrap()` does. It a big improvement over any random access potentially implicitly exploding.
And in turn, the claim above was that some languages have plain pointers that aren't dangerous.
Yes, you can put a pointer into an Option that can fail, but that's a different issue. The point is that "can fail" is not built directly into the pointer type, and you can use pointers that don't have that risk.
And to be clear, that claim is not directly addressing the issue of SQL null. It's a baseline discussion of what pointers actually imply by nature of being pointers. We can then better build upon that knowledge after we separate "refers to a data location" and "might not have contents" into separate attributes.
I am a Rust novice but I have not found a way to get to uninitialised memory in safe Rust. Yet.
Yes you can: https://doc.rust-lang.org/std/ptr/fn.null.html
You just won't use it unless you're doing FFI or similar things.
I meant "using null pointer" means dereference it. But careless language....
/*
int g() {
volatile int x;
return x;
}
*/
import "C"
import "fmt"
func main() {
fmt.Printf("%d\n", C.g())
}
Which is fair and true, but you're chasing down a pointless detail. The point isn't that go is memory unsafe. It's not. The point is that Go's type-system is not powerful enough to express various types of type-safety, and as such it's an error-prone language where you can expect null pointer exceptions frequently.
Still. Rust is infinitely better in this regard. Go feels like a crude hammer, especially regarding the default interaction between deserialization and missing struct members.
There are other, very convincingly better options to this that many in this thread have been trying to teach you about in the expectation that your responses have been in good faith.