In some languages, the concept of "may or may not be there" is cleanly separated from "exists in a separate block of memory". There's plenty of pointers which will never be nil - checking that they're nil at the entry and exit points of every function is line noise.
I don't think the parent was advocating for checking for nil before/after each function, but rather noting that this option pattern doesn't buy you any more type safety in Go because there's nothing enforcing you to check appropriately any more than there is for a pointer.
The salient rebuttal is that this pattern is a strong hint to check, whereas a pointer is ambiguous (it's unclear whether or not a bare pointer may ever be nil, but you would only use this pattern to be explicit that a check is needed). This pattern can also support value types so you don't have to worry as much about unnecessary allocations.
If this question is in good faith, for example Kotlin differentiates between the nullable T? and the non-nullable T. An if x != null check automatically casts T? to T. You can't call a method on T?, preventing null pointer exceptions. C# and Typescript have similar language support. Other languages push users away from the problem by favoring monadic Optional/Maybe solutions.
There are some differences here, but you can't for instance use a string pointer with string functions in go either. IMO The distinction between pointer and optional is not as vast as people make it out to be.
(But thanks, I overlooked T? conversions inside if.)
No you can't, but Go will happily de-reference the pointer without a null check, and your "string" will blow up in production: https://go.dev/play/p/7EVa7q6VgIM
I don't think that's quite true. It's sort of the same in how it's used, but the main difference is that T? (or T | null) is a union, and Optional/Maybe/Option is a sum type. Out of all the implementations I've seen, T? can't be nested - you can't have T??, whereas it's quite possible to have a Option<Option<T>> (and it's sometimes useful).
It's semantically similar but not syntactic sugar, since it is not translated to Optional or wrapper types, so it also doesn't incur the overhead of Optional.
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.
Type systems can enforce that types always contain a value of that type and cannot be null. There is another type that is either null or a value of the enclosed type.
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.
>> Sane languages have pointers which either can't be null or require you to check explicitly. Rather than leaving it to explode at runtime.
> 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 },
}
}
There are a few dozen other things you can do with an Option that handle the rarer use-cases, but the above are like 95%+ of what you want.
You're explicitly choosing to panic if it is None. Would never pass a code review unless you can in very clear terms tell why it will never now or in the future be none.
The point is that you can't use the inner value without choosing a course of action if it happens to be none.
The quote is talking about plain pointers being dangerous.
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.
Zig encodes optionality separately from pointer-ness, like Rust. You don't have to ask about unwrapping None in cases where None is not a member of &T.
But I know you'll say that 'import "C"' or 'import "unsafe"' is the same thing as using an unsafe block in rust or such, and really shouldn't count against go.
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.
You can't. But a runtime panic also very easily causes an outage. At least it's not as subtle.
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.
You can't. But you can absolutely have a `nil` that will unavoiad runtime panics if you don't check it. And further, you only can't do this because go defines by fiat that the zero-value of a type must be legal. Of course, this is wildly inconvenient and annoying for many types, including those that come bundled in the standard library.
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.
If something may or may not be there, that should be a clear part of its type that the compiler checks you handled (even if it's just you deciding to panic, because sometimes that's the right thing to do). Then there can be a type for just the thing, no hidden possibility of it not being there that you have to check for, and almost all code can be written for the type that is guaranteed to be there, with only a little code dealing with only possibly-there values.