3 ms·
I can't think of any situations where (1) would be insufficient, but I'm probably wrong. But I agree that setting an isValid bit for every object is overkill.
by SQueeeeeL 5y ago
I can't think of any situations where (1) would be insufficient, but I'm probably wrong. But I agree that setting an isValid bit for every object is overkill.
- saghm 5y agoI think the point is that it would be nice to be able to express the idea of a value not being present without having to risk accidentally trying to dereference a nil pointer. That's what Option brings to the table, although arguably Go could just provide an implementation of that like they do for slices and maps without actually having to introduce full generics to the language.
- chakkepolja 5y agoapart from what sibling comment mentions, declaring as pointer will often result in a heap allocation in Go.
- simiones 5y agoWell, in the link that you shared, Tony Hoare explains in quite some detail why having support for null pointers is not great. Additionally, a *Vec3 is more than `Vec3` or `null`. For example, the following code will behave very differently based on whether optionalVec is Vec3 or *Vec3. optionalVec := Vec3{0, 0, 0} foo(optionalVec) fmt.Printf("theVec: %+v", optionalVec) // would print {0, 0, 0} with an Optional[Vec3] type // will actually print {2, 0, 0} with *Vec3 ... func foo(optionalVec *Vec3) { if optionalVec != nil { optionalVec.x += 2 //we use a different origin } [...] }