4 ms·
Note that these is absolutely zero gains with the second approach if the compiler doesn't enforce it. And I very much don't envision that the Go compiler would
by hota_mazi 9y ago
Note that these is absolutely zero gains with the second approach if the compiler doesn't enforce it.
And I very much don't envision that the Go compiler would be modified to make sure that `x.value` is never referenced unless the presence of that value has been confirmed by an earlier statement.
- alkonaut 9y ago> Note that these is absolutely zero gains with the second approach if the compiler doesn't enforce it. The compiler enforces it by the fact that you can't pass in the return value from one thing (that might not be a valid value) into the next function that takes an argument that must be a valid value. Your objection that "but I can unwrap/call value without checking so it's useless" is a commonly raised objection - but it's a false one. With nulls var x = get_something do_something(x) // ok even if x is null With option/maybe x = get_something do_something(x) // compiler err x = get_something do_something(x.value) // ok, *concious action by developer* x = get_something if x.hasvalue do_something(x) // ok The difference in safety between having to make a concius unwrap IS the whole point of the feature. This works exactly the same everywhere. You can always ".unwrap()" in Rust for example. Having to unwrap, or unwrapping without checking first isn't wrong, in fact it's often right. Unwrapping the value first means "extract the value if it exists, or otherwise panic right here". This decision to "assume success or otherwise panic" is a clear intent that the next developer can read.