3 ms·

What about wrapping nil in a Maybe or Option type?

aarjaneiro 4mo ago
This is more about a hard dependency which causes a function to early exit
flowerthoughts 4mo ago
In this case, the missing piece in Go is the NonNullable hint. That would make it clear that null checks aren't needed, enforceable by the type system, and lintable. Option types just forces you to do the check, but doesn't remove the need for it. Now that we have generic types, a NonNullable intrinsic type seems doable...
- sail0rm00n 4mo ago
  References like C++, maybe?
- cubefox 4mo ago
  Or a set theoretic type system with union type declarations (foo|null), like in TypeScript.
- ThePhysicist 4mo ago
  It's quite easy to write a generic Maybe struct that performs most of the encapsulation that Rust's Maybe does i.e. allow unwrapping of the inner type through a function or handling the nil case through a switch like statement. I've never seen this in the wild which makes me think people don't care about it too much. And of course it's runtime based so no compile time guarantees, and just to preempt the expected replies I know it's not the same what Rust is capable off and Rust is of course a much much much much better language than Go. Personally I do experiment with these things as it makes code more readable, it just seems adoption for generics and what you can do with them is still quite low in the broader community. That said I do not deal with null pointer exceptions much at all, and when I do it's often relatively simply to spot and fix, so for me it's not a large issue.
yencabulator 4mo ago
Go fundamentally cannot not have a zero value. For Option that could be fine, you can say zero value is None and solve the superficial issue, but you have no way of preventing the x in Some(x) from being a zero value. For Result, zero value being Ok(zero_value) seems like a very bad idea. Go's idea of zero values is everywhere in the language spec. Removing it would be Go2, not the same language.

This is more about a hard dependency which causes a function to early exit

In this case, the missing piece in Go is the NonNullable hint. That would make it clear that null checks aren't needed, enforceable by the type system, and lintable. Option types just forces you to do the check, but doesn't remove the need for it. Now that we have generic types, a NonNullable intrinsic type seems doable...

sail0rm00n 4mo ago
References like C++, maybe?
cubefox 4mo ago
Or a set theoretic type system with union type declarations (foo|null), like in TypeScript.
ThePhysicist 4mo ago
It's quite easy to write a generic Maybe struct that performs most of the encapsulation that Rust's Maybe does i.e. allow unwrapping of the inner type through a function or handling the nil case through a switch like statement. I've never seen this in the wild which makes me think people don't care about it too much. And of course it's runtime based so no compile time guarantees, and just to preempt the expected replies I know it's not the same what Rust is capable off and Rust is of course a much much much much better language than Go. Personally I do experiment with these things as it makes code more readable, it just seems adoption for generics and what you can do with them is still quite low in the broader community. That said I do not deal with null pointer exceptions much at all, and when I do it's often relatively simply to spot and fix, so for me it's not a large issue.

yencabulator 4mo ago

Go fundamentally cannot not have a zero value. For Option that could be fine, you can say zero value is None and solve the superficial issue, but you have no way of preventing the x in Some(x) from being a zero value. For Result, zero value being Ok(zero_value) seems like a very bad idea. Go's idea of zero values is everywhere in the language spec. Removing it would be Go2, not the same language.