[dtech]

If this question is in good faith, for example Kotlin differentiates between the nullable T? and the non-nullable T. An if x != null check automatically casts T? to T. You can't call a method on T?, preventing null pointer exceptions. C# and Typescript have similar language support. Other languages push users away from the problem by favoring monadic Optional/Maybe solutions.

[tedunangst]

There are some differences here, but you can't for instance use a string pointer with string functions in go either. IMO The distinction between pointer and optional is not as vast as people make it out to be.

(But thanks, I overlooked T? conversions inside if.)

[ricardobeat]

No you can't, but Go will happily de-reference the pointer without a null check, and your "string" will blow up in production: https://go.dev/play/p/7EVa7q6VgIM

[akavi]

The distinction between pointer and optional is not vast. The distinction between pointer and not optional is.

The whole idea of optional is to make not optional possible.

[morelisp]

You can call a value method on a nil pointer and it panics, though, which I think was a mistake.

[nemothekid]

>The distinction between pointer and optional is not as vast as people make it out to be.

The billion dollar mistake is overblown?

[adastra22]

T? is just syntactic sugar for Optional/Maybe, no?

[shirogane86x]

I don't think that's quite true. It's sort of the same in how it's used, but the main difference is that T? (or T | null) is a union, and Optional/Maybe/Option is a sum type. Out of all the implementations I've seen, T? can't be nested - you can't have T??, whereas it's quite possible to have a Option<Option<T>> (and it's sometimes useful).

[MrJohz]

Roughly, yes. But that's the point: an Optional type along with static typing preventing misuse can prevent these sorts of errors entirely.

[dtech]

It's semantically similar but not syntactic sugar, since it is not translated to Optional or wrapper types, so it also doesn't incur the overhead of Optional.

I actually like the language support more, as it flows a lot better than the (flat)map chain you get in monadic style. Similar to async/await v.s. Future.