3 ms·
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 w
by solar-ice 4y ago
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.
- throwaway894345 4y agoI 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.
- IshKebab 4y agoIs "some languages" just Rust?
- solar-ice 4y agoAlso Swift, and various functional languages too, although "exists in a separate block of memory" is basically the default there.