[maxbond]

Sure, you can panic unwrapping a None, but there are two important distinctions.

First, this is a controlled panic, not a segmentation fault. The language is ensuring that we don't access the null pointer, or an offset from the null pointer. Null pointer access can be exploitable in certain circumstances (eg, a firmware or kernel). Your use of "exception" suggests you're thinking about it in Java terms however, and Java is equivalent here.

Second, you can only encounter this in explicit circumstances, when you have an Option<T>. Wheras in languages with a null type, any variable can be null implicitly, regardless of it's type.

[benibela]

>First, this is a controlled panic, not a segmentation fault.

But a segmentation fault is also controlled

>Your use of "exception" suggests you're thinking about it in Java terms however, and Java is equivalent here.

No, I am thinking in Delphi terms. It is overspecialized to Windows userspace. Windows gives an Access Violation, and that can be caught, and Delphi throws it as exception

>Second, you can only encounter this in explicit circumstances, when you have an Option<T>. Wheras in languages with a null type, any variable can be null implicitly, regardless of it's type.

Delphi has both nullable types and null-safe types

[maxbond]

> But a segmentation fault is also controlled

A segmentation fault may not happen (which is to say, we may corrupt memory or worse) if the null pointer is mapped into memory (as in an embedded or kernel context) or if it's accessed at a large offset, which results in a pointer that's mapped into memory. This may be rotten luck or it may be exploited by an attacker.

> No, I am thinking in Delphi terms.

Fair enough, I don't know Delphi. I'll take what you're saying about it as read.