Why nullable types?

I think dart made the wrong choice here, but I&#x27;ve never used the language personally or professionally.<p>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&lt;number&gt; but none of that is even mentioned in this piece (likely cause then its harder to justify picking nullable types instead)<p>I also found the Some(Some(3)) example just plain wrong. In those scenarios, typically you just use chain (aka flatMap) instead of map... Seems odd this was even included as a motivating reason when this is very much a solved problem.<p>I&#x27;m certainly biased, as I think FP is an incredible mental model for coding and it seems to be catching on in lots of places too.<p>I understand language designers have to make choices that benefit their users now and be as simple as possible to opt into without any overhead to account for changes, but man, what a missed opportunity to give developers better tools and mechanisms in addition to opening up the doorway for many people to functional programming. But even Java has support for optionals.<p>Overall, this appears to be like a missed opportunity and the justification doesn&#x27;t seem to really reflect an understanding of the benefits optionals provide, and misconstrues their use and capability.

&gt;There are two main solutions: Use an option or maybe type or Use a nullable type<p>I don&#x27;t get it. These are literally all exactly the same thing, all slightly varying in ergonomics and compiler support. They may differ slightly but to call them two different categories of solution is just creating a false dichotomy for yourself.<p>&gt; However, the type system is a little more flexible than with option types. The type system understands that a union type is a supertype of its branches. In other words, int is a subtype of int?. That means we can pass a definitely-present-integer to something that expects a maybe-present-integer since that’s safe to do.<p>You can do that in Swift, despite being placed as an example of &quot;Solution 1&quot;.<p>&gt; The short answer is that, yes, it is entirely possible to live without null, and languages like Rust do.<p>If you can call say that Swift has &quot;null&quot;, then you can equally say that Rust has &quot;null&quot;--it&#x27;s called &quot;None&quot;. The only way &quot;None&quot; and &quot;null&quot; from other languages differ is in built-in compiler support.

Back when I was really into FP, but didn&#x27;t use functional languages, I decided that the humble list was the answer to all my problems. Operations over lists behave the same regardless of their length, and a 0 element list is not a special case. Say you want to send mail to someone&#x27;s mailing addresses:<p><pre><code> addresses = user.addresses() for address in addresses { send_mail(address) } </code></pre> If they have no addresses, the program doesn&#x27;t blow up. If they have one address, they get mail!<p>Of course, it&#x27;s possible that having two addresses is just as annoying as having 0 addresses, in which case lists don&#x27;t help you. Someone will add a second address, and then you won&#x27;t know where to walk to to go see them.<p>I&#x27;ll also point out that it&#x27;s the same number of lines of code as just handling null:<p><pre><code> address = user.address() if address != null { send_mail(address) } </code></pre> So it&#x27;s kind of a wash, and I haven&#x27;t really thought about it since.

Me and my team prefer Option to nullable types. Option is much more clear and idiomatic FP than nullable types.<p>Granted, Option.map and flatMap and nullable type ?.let{} are functionally equivalent but the former just reads so much better, and we want not just functor and monad but applicative as well, no?<p>Eg given a List&lt;Option&gt;, we can use applicative to declaratively and with referential transparency etc etc (you know the usual FP sales pitch) turn it into an empty list if it contains a single non-populated option, or a list of Foo if all options in the list are populated.<p>With nullable types I don&#x27;t think you could do it as declaratively and elegantly.<p>Actually, even if you could, it&#x27;s kind of beside the point...<p>To me, the point is, Option has been designed from scratch to be an FP style Maybe type with all that comes with that in terms of it being a functor, applicative functor, monad etc etc whereas while nullable types in some ways are functionally equivalent, a nullable type doesn&#x27;t implement a Functor interface, or a Monad interface, or an Applicative interface, and when it behaves like it does, it&#x27;s mostly kind of by accident driven by a pragmatic need, not any real understanding of reusable, lawful FP abstractions.

&gt; it is entirely possible to live without null, and languages like Rust do.<p>It seems as though there is this common misconception that Rust does not have a concept of null. Rust <i>does</i> have null pointers [1]! The reason many people do not see null often is because working with and dereferencing raw pointers is an unsafe operation<p>1: <a href="https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;std&#x2F;ptr&#x2F;fn.null.html" rel="nofollow">https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;std&#x2F;ptr&#x2F;fn.null.html</a>

I agree that union-typed null was the best solution for Dart, but I think many of the article&#x27;s criticisms of option types aren&#x27;t good.<p>&gt; We can’t perform arithmetic on an Option&lt;int&gt; any more than we could on a List&lt;int&gt;.<p>Why not? One sensible definition is<p><pre><code> Some(x) + Some(y) = Some(x + y) _ + _ = None() </code></pre> &gt; In fact, with Dart, we’ve found that most existing code is already statically null safe<p>This is a very good reason to use union types — lots of programs and lots of people are used to thinking this way, and pulling that out from under their feet wouldn&#x27;t be very nice.<p>&gt; Nullable types, since they have no explicit runtime representation, are implicitly flattened.<p>Yes, flattening things that shouldn&#x27;t be flattened is the biggest problem with union types. Different people will assign different meanings to null, and it&#x27;s a real headache when trying to write generic code. Discriminated unions make this a no-brainer.<p>&gt; With nullable types, since there is no representation difference, you can pass a value of the underlying type directly: takesMaybeInt(3);<p>That&#x27;s a very minor difference, but if it&#x27;s that important, Rust lets you write<p><pre><code> fn takesMaybeInt(x: impl Into&lt;Option&lt;i32&gt;&gt;) { ... }</code></pre>

I sometimes wonder if the problem is that we don&#x27;t have <i>enough</i> nulls.<p>null is typically used as a flag value, but the meaning can be ambiguous: maybe it&#x27;s the absence of a value, maybe an error occured, etc. Sometimes it has more than one meaning for the same type.<p>Maybe types should be allowed to declare multiple nulls (effectively like an Enum in java) for different flag values. Operations on the different nulls would throw specialized exceptions indicating why that particular null value exists. Equality... hmmm.

Is it me, or is the real answer: it&#x27;s hard to retrofit optional types into a language, but you can add nullable types.

Working with Dart now and it looks like it’s straight from the 90’s in a lot of aspects. It is not s bad as vanilla JS but when given a clean slate to design a new platform so many better choices could have been made...

I think saying that Option types are different from nullable types is not true. They differ at the semantic level, around how you can interact with them (one requires you to case on whether or not the value is there, the other requires you to do that with an if statement), but at the type level the describe the same construct.<p>I think saying something is not the same as something else, when evidently the difference can to reduced down to syntactic sugar is a bad way categorizing and differentiating types.

This 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.<p>It&#x27;s not unique to Dart (Python, ...), but many languages that are popular around here tend to favor expressiveness over usability.

Wow tough crowd. I appreciate the pragmatic approach taken here, and as long as there is type safety round nulls im happy to use the language.<p>Nitpick: As of C# 8 they’ve mostly solved nullable types for classes too with nullable reference types (though retrofitting it made it awkward and imperfect).

For anyone interested, there&#x27;s also an excellent article on how nullable types work in Dart, that&#x27;s more of a deep dive:<p><a href="https:&#x2F;&#x2F;dart.dev&#x2F;null-safety&#x2F;understanding-null-safety" rel="nofollow">https:&#x2F;&#x2F;dart.dev&#x2F;null-safety&#x2F;understanding-null-safety</a>

I guess a third option would be to use an &quot;Option&quot; but with much more syntactic sugar. So, rather than calling func(some(3)), you&#x27;d just call func(3) and the compiler would automatically wrap it up. Func would be declared this way: def func(int?) to indicate that it&#x27;s an optional type. IMO you get the best of both world. And then, in many places in the code, you&#x27;d have to do &quot;r?.foo()&quot; if r is an Option type. It&#x27;s different than javascript where the &quot;?&quot; isn&#x27;t enforced by the compiler.

Previous, with a comment from the author: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25334248" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25334248</a>

Good article, but there is no &quot;choice&quot;. You need both and the article even explains why!<p>You need union types if you have subtyping to avoid wrapping&#x2F;unwrapping all the time.<p>And you also need option&#x2F;maybe types for the cases where you must not lose information at runtime. These types can implemented by union types even, by simply &quot;tagging&quot; (= wrapping) the runtime values with a class).<p>A good language gives you both out of the box.

I have this funny question all the time: why dont we just use a bit boolean for representing option&#x2F;nullable&#x2F;unknown instead? (one bit of hasValue&#x2F;isEmpty like C# HasValue, but like struct uncertain_value&lt;T&gt; { T value; bool dont_care: 1; } and uninitialized value f&lt;T&gt;() =&gt; uncertain_value&lt;T&gt; { dont_care = 1 })

This is not intended as an attack, but a genuine question: what does Dart offer over any other language? Why would I choose Dart?

Nullable type is the biggest mistake in all the &quot;modern&quot; languages<p>It should be a type Optional&lt;T&gt;, not built into a language, it make no sense memory wise<p>It&#x27;s like NULL, it should stay, it is not an issue, it is how computers work!!!!!!!

If we look at set theory the NULL set is a valid set. The problem with NULL is often it&#x27;s just treated as zero or if passed to a language that does not have NULL it&#x27;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.<p>It&#x27;s why for instance with GPS coordinates NULL island exists.<p>However, errors aside NULL is a perfectly logical value to encounter or need.