5 ms·
If you want a field to be able to be not-set, you just need to specify that by making it an `Option<_>` type. So like, if the field is a number, make it an `Opt
by apendleton 5y ago
If you want a field to be able to be not-set, you just need to specify that by making it an `Option<_>` type. So like, if the field is a number, make it an `Option<u64>` -- that way you can distinguish between not-set (`None`) and set to zero (`Some(0)`).
Edit: whoops, misread which language it was you were frustrated with. Nevermind!
- tylerhou 5y agoI know you’re giving helpful advice, but the author is talking (complaining) about Golang, which has no option typing (unless you want to use a pointer).
- the_duke 5y agoYou misunderstood, parent is complaining about Go, not about Rust. In Go you would have to use a pointer to represent Option<T>, which makes code really awkward. Go serialization really has quite a few issues apart from default initialization. Configuration by somewhat weird struct tag strings which are only evaluated/validated at runtime, de/serialization is all done via reflection (unless you want to use code generation), ...
- eyelidlessness 5y ago> In Go you would have to use a pointer to represent Option<T>, which makes code really awkward. This sounded surprising to me, then I remembered Go doesn’t have generics. I imagine this won’t be as much of an issue when it does?
- throwaway192874 5y agoPerhaps if they were to remove the concept of nil in golang, but since they are all about backwards compatibility (which is nice to be fair), I don't think there's much change of seeing mainstream adoption because of how many existing projects will rely on default value in certain circumstances I'd love to be proven wrong, but even with generics if you start using option types, it's going to be like JS and TypeScript where you'll have some parts nicely typed and others are the wild west
- the_duke 5y agoEmulating ADTs without language support/pattern matching is quite awkward. A prime example is std::optional in C++. .map() et al only get you so far. When extracting the value in Go you either have to return a pointer / error pair or abort. Both of which introduce awkward code patterns and potential for misuse.
- hawk_ 5y agowhen Optional<u64> is used in rust what's the memory layout like? is the absence tracked using a pointer which is null or a bitvector of optional fields?
- goldsteinq 5y agoOption<u64> would look like tagged union in memory, so one bit "tag", 8 bytes u64 and padding. If type inside of Option<_> has invalid values (like references which can't be null) one of these would be used for None, so Option<&T> is the same size as &T.
- hawk_ 5y agothanks and is the padding for aligned access (wasted space) or just full byte (poor performance on non x86/64 like architecture)? because that's the interesting part as to what's the tradeoff chosen and whether a dev can choose a different one. Any doc references are appreciated.
- Nullabillity 5y agoThey are padded for aligned access, so on amd64 Option<u64> will be 16 bytes.[0] However, the unused discriminant values are counted as niches for enums wrapping that, so Option<Option<u64>> is still 16 bytes (for example). [0]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ccfc6db189ae326a52d3d5187fce11fc https://play.rust-lang.org/?version=stable&mode=debug&editio...
- ahahahahah 5y ago> If type inside of Option<_> has invalid values Can it actually use any general invalid bit pattern? I expect that it only supports an optimization for values that cannot be zero (and then it uses zero to indicate None).