[tedunangst]

Well, this is a thread about storing sql null. I'm trying to suss out how sane languages represent sql null in a way that can't go wrong. So far the answers mostly seem to be use a type that can't represent sql null or use a type that explodes when you use it wrong. With a side of real programmers don't let bugs pass code review.

[stouset]

With all due respect, it appears as if you have entered this conversation with this belief and have used that perspective as a filter when other commenters have tried to correct that perspective.

It may be surprising to learn that languages without implicitly-nullable types are real, but you should understand that none of these people would be trying to tell you about this if these languages simply exploded any time you used them the wrong way.

[avgcorrection]

> I'm trying to [sass] out how sane languages represent sql null in a way that can't go wrong.

There is a difference between a type Pointer where `null` is an instance of that type and a type Box which only has valid (can be dereferenced) values. If the language has e.g. algebraic data types and pattern matching then Option(al)<Box> can be safely matched on and Box can be used in the branch (the pattern match arm) where Some(Box). Meanwhile in a language with Pointer and no flow analysis any dereference of Pointer could lead to some kind of "panic".

Say "unwrap()" all you want but the two approaches are clearly very different.

[winstonewert]

Where did anyone anywhere in this thread claim that you could "represent sql null in a way that can't go wrong?"

Yes, Rust options explode if you unwrap a None. But that's explicitly what `unwrap()` does. It a big improvement over any random access potentially implicitly exploding.

[anonymoushn]

It seems like sql types that include null and non-null values are a union of at least two different types. In general, if you write code to handle a tagged union that has "panic!" in one of the prongs, you'll get panics. Don't do that?