|
|
|
|
|
by hota_mazi
3436 days ago
|
|
> it's a language-level builtin rather than something you can use in your own libraries The only people who still think that a library approach is superior to a compiler approach are Scala users. I'll clarify this for you: if it's a library construct, it can be ignored. And as a matter of fact, there is nothing in Scala forcing you to use `Option`. You can completely ignore it and enjoy your time diagnosing NullPointerExceptions everywhere. When a feature is enforced by the compiler, such as Kotlin and Ceylon, you don't get any easy way out: you have to think about null cases or you will not be able to compile your code. Period. |
|
But the right way to represent absence - whether you call it null or option or something else - is clearly with a normal type that follows the normal rules of the language, not a special language-builtin type with special language-builtin rules. Some light syntactic sugar for commonly-used types makes sense (like Ceylon's "?"), but what it desugars to should always be something you could write a normal library type for. Indeed if your language doesn't let you implement the constructs you need for this kind of type in a custom type in a library, that should be a red flag that your language isn't expressive enough for general-purpose use.