I have this funny question all the time: why dont we just use a bit boolean for representing option/nullable/unknown instead? (one bit of hasValue/isEmpty like C# HasValue, but like struct uncertain_value { T value; bool dont_care: 1; } and uninitialized value f() => uncertain_value { dont_care = 1 })
Why nullable types?
61–70 of 119 posts
Re: Why nullable types?
#62I have this funny question all the time: why dont we just use a bit boolean for representing option/nullable/unknown instead? (one bit of hasValue/isEmpty like C# HasValue, but like struct uncertain_value { T value; bool dont_care: 1; } and uninitialized value f () => uncertain_value { dont_care = 1 })
What do you see as being the benefits of this approach?
Re: Why nullable types?
#63This is a very readable writeup. From a distance, Dart seems to focus on usability, while other languages focus more on simplicity (Go) or expressive power (most modern languages). I appreciate the focus on usability.
It's not unique to Dart (Python, ...), but many languages that are popular around here tend to favor expressiveness over usability.
Re: Why nullable types?
#64This is a very readable writeup. From a distance, Dart seems to focus on usability, while other languages focus more on simplicity (Go) or expressive power (most modern languages). I appreciate the focus on usability. It's not unique to Dart (Python, ...), but many languages that are popular around here tend to favor expressiveness over usability.
> Dart seems to focus on usability, while other languages focus more on simplicity (Go) or expressive power (most modern languages).
Author here. I think we try to focus on all three, but the latter are largely constrained by the language as it was designed in Dart 1.0 (which was mostly done by a different set of people than the ones who work on the language now).
I do wish Dart was a simpler language and worry a lot about the added cognitive load of the usability features we add. But it's really hard to take away features. In order to make non-nullable types a non-breaking change, we added a general versioning system to the language [1]. We have to use it carefully, of course, because users don't like migrating code. But I have some hope that we can use that to gradually simplify the language over time. Complexity has a direct usability cost.
We also care a lot about expressiveness, but I think other languages tend to define that in terms of "how many different things can you express in a minimal amount of code"? With Dart, we weight more by how often you want to certain things, and by how you want to express that. We're willing to make some things more verbose if it makes common things shorter or more familiar.
[1]: https://dart.dev/guides/language/evolution#language-versioni...
Re: Why nullable types?
#65If we look at set theory the NULL set is a valid set. The problem with NULL is often it's just treated as zero or if passed to a language that does not have NULL it's pretty often to just treat it as Zero. This bit equivalence between zero and NULL zero is often what you see lead to problems. It's why for instance with GPS coordinates NULL island exists. However, errors aside NULL is a perfectly logical value to enco…
> NULL is a perfectly logical value to encounter or need. Great! Assign to it the type Null. This is legal: Null myNull = null; Make this illegal: Integer i = null;
This is essentially what Dart does:
https://api.dart.dev/stable/2.10.4/dart-core/Null-class.html
The main change with adding nullable and non-nullable types to the language is that we no longer treat Null as a subtype of all types. Instead, you have to opt in using "?", which is basically syntactic sugar for "| Null".
Re: Why nullable types?
#66I have this funny question all the time: why dont we just use a bit boolean for representing option/nullable/unknown instead? (one bit of hasValue/isEmpty like C# HasValue, but like struct uncertain_value { T value; bool dont_care: 1; } and uninitialized value f () => uncertain_value { dont_care = 1 })
Given a 64-bit variable, you can fill it with 64 bits of value, or 64 bits of pointer to some value elsewhere.
With your scheme that would be 63 (which I'm not objecting to).
Pointers are already special-cased to only contain 0 already. There's no use-case for having 63 bits of pointer and an extra bit saying "ignore the other 63 bits".
As for the value case, I think the argument is pretty similar. Why store 63 bits of value if the 64th bit says to ignore them?
If you're not talking memory layouts and are looking at adding an extra field to a struct/class. Take you value field - if it's not initialised yet, and null doesn't exist, then what is its state?
Re: Why nullable types?
#67[deleted]
Re: Why nullable types?
#68Is it me, or is the real answer: it's hard to retrofit optional types into a language, but you can add nullable types.
Re: Why nullable types?
#69Nullable type is the biggest mistake in all the "modern" languages It should be a type Optional , not built into a language, it make no sense memory wise It's like NULL, it should stay, it is not an issue, it is how computers work!!!!!!!
You seem to have a very strong opinion about the issue, but I cannot tell whether you prefer a missing value to be represented by null or by Option.empty.
Re: Why nullable types?
#70I think dart made the wrong choice here, but I've never used the language personally or professionally. I give the author the benefit of the doubt but Optionals are so much more powerful than what this article covers. You can map, filter, reduce, chain, compose functions that all work with optionals, and lift functions that work on numbers (or any other type) to be functions that work on Optional but none of that is…
> You can map, filter, reduce, chain, compose functions that all work with optionals, and lift functions that work on numbers (or any other type) to be functions that work on Optional but none of that is even mentioned in this piece (likely cause then its harder to justify picking nullable types instead) Maybe I'm missing something, but I don't see how that's special to option types. Here's a set of extension methods…
> I'm not sure what you mean by "compose".
The simplest illustration is the ability to have multiple levels of semantically meaningful optionality:
Option> is a meaningful type, and None, Some(None), and Some(Some(1)) are all meaningfully-distinct values. int? doesn't compose to int?? and has no good way to differentiate what Option> represents as None and Some(None).