3 ms·
I’ve ran into a few edge cases where nil was a desirable feature. But on the whole I do agree with you. Those situations I mentioned could have been solved anot
by hnlmorg 2y ago
I’ve ran into a few edge cases where nil was a desirable feature. But on the whole I do agree with you. Those situations I mentioned could have been solved another way if nils weren’t available. It would have been more code but it might have had the side effect of that codes behaviour being more explicit. So potential win-win.
This argument feels somewhat moot though. I cannot see how Go could ever reverse their nil decision because it’s so core to how interfaces work that I suspect it would end up being a massive breaking change.
- masklinn 2y ago> I’ve ran into a few edge cases where nil was a desirable feature. But on the whole I do agree with you. Those situations I mentioned could have been solved another way if nils weren’t available. In every language where pointers / references / values are not universally nullable, it's just an opt-in away, either as a wrapper type (Option/Maybe), a union type (T* | Nil), or a built-in language feature. Either way you can pretty much always say "this may be nil", the difference is that you can't use a nullable value where a non-nullable value is expected, the language will require explicit checking (or in the worst case coercion).
- hnlmorg 2y agoAh ok. That makes a lot more sense.