3 ms·
The main downside to this approach is that you'll still have to deal with the zero value, which for interfaces is going to be nil.
by atombender 3y ago
The main downside to this approach is that you'll still have to deal with the zero value, which for interfaces is going to be nil.
- Groxx 3y agoWhile I agree nils are a problem with this: as long as they have access to the type at all, they can create zero values. E.g. var c color.Color That's a valid color whether it's a nil interface value or an empty typed string. You can return a private type to prevent this, but that also means they can't refer to it as an argument or return value anywhere outside the implementing package, which is a rather severe limit in many cases. Sometimes* I really miss constructors. *: all the time
- masklinn 3y agoNo matter how Go solves the issue (assuming it ever does), that will be part of it: unless it goes through a revolution and strips out and forgets about ubiquitous default values (which I don't think it will, C# has barely just dipped its toes into that pool) any sort of sum-type-like construct will need a default value. And I'm not sure `nil` (a clearly corrupted / missing value) is any worse than picking an actual valid value the way non-pointer types do.