Comment by dmantis
2 days ago
Wouldn't Rust's Result or Go's error checking prevent that?
While not mandatory, a person would probably use it instead of the * hack.
Simply because the calling side wouldn't have an option to forget the check like with the NULL case
Rust and go still make it pretty easy to not check results if you don’t care about the success value (lots of code just does `let _ = foo()`), but if you do want the value (like with a hashing function), Rust makes it really hard to not check the error too. There’s no syntax to say “assume this worked and give me the success value, including whatever garbage is there if it’s not set”:
- result.unwrap() will panic if it failed
- result.ok() throws away the error but gives you a None value instead (still can’t use it as if it’s a success)
- matching on the Ok variant and doing nothing on the Err variant, you only get to use the success value inside the Ok arm
Etc etc.
The problem is when the compiler says “NULL is a valid instance of T”, which go lets you do, and rust doesn’t (without using the unsafe keyword and intentionally casting a null pointer, which you don’t do by accident.) Go lets you write code like `var hash string; hash, _ = hashfn()` and it compiles and now you have null instead of a valid hash.
Minor nit, strings are never nil in Go, so that would be "" instead. Usually nil is only a valid instance of pointer-to-T. The point stands though, a common pattern is "defer foo.Close()", the Close() signature almost always returns an error and almost no one checks it...which is probably fine, but not automatically fine.
> NULL is a valid instance of T
This by the way is Tony Hoare's famous "Billion Dollar Mistake"
A NULL pointer for error would be a safe interface where you get a trap when there is no value.