Timeline for Why F#, Rust and others use Option type instead of nullable types like C# 8 or TypeScript?
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot | Commonmark migration | |
| Jun 11, 2020 at 8:20 | audit | First posts | |||
| Jun 11, 2020 at 8:21 | |||||
| Jun 4, 2020 at 2:29 | comment | added | Mooing Duck | @Kain0_0: Considering the opening section is "Null is overloaded", it's really easy to reach that interpretation. Also, because literally everything up to " powerful type composition system to create the desired behaviours." also applies to explaining why "Optional" is bad. :D | |
| Jun 4, 2020 at 1:18 | comment | added | Kain0_0 | @MooingDuck Right, rereading my answer I can see how you come away with "NULL is bad because its Overloaded". My point wasn't that its bad because its overloaded, otherwise most human languages would be bad. I was trying to illustrate that the compiler can't just guess the writers intention here, the meaning can be so easily overloaded. But thank you for pointing out where I can improve my answers. | |
| Jun 3, 2020 at 14:44 | comment | added | Mooing Duck | @Kain0_0: Sure, I don't disagree with that. That's a valid argument for Optional being better than null. But "Null is a problem because it's overloaded" is not a valid argument. They're separate arguments, and only the first is valid. And the valid one isn't stated explicitly in this answer. It's only vaguely hinted at in the final section. | |
| Jun 3, 2020 at 10:18 | comment | added | Kain0_0 | @MooingDuck In the C# case this is correct. But in a more powerful type savy language Optional indicates to the compiler that both cases must be handled gracefully by the program. Such languages will fail to compile a program that cannot be verified to handle the NULL case, and the Non-Null case. Thus it isn't possible for such a program to dereference NULL. | |
| Jun 3, 2020 at 10:14 | comment | added | Kain0_0 | @ChayimFriedman NullReferenceException means attempted to dereference a Null. That makes no statement about whether the program considers that a valid state or not, just that the language considers the program malformed. The prevention for such in a language would not be Optional but non-nullable reference types, or value types - allowing the program to preclude the invalid state. Optional provides the converse, allowing a program to indicate that NULL is a valid state, and with appropriate language support ensure that the case is suitably handled precluding the language from throwing. | |
| May 29, 2020 at 15:06 | comment | added | Toothbrush | @ChayimFriedman And Option<&ptr> in Rust is the same size as &ptr and usize. | |
| May 29, 2020 at 15:05 | comment | added | Toothbrush | @ChayimFriedman No, Rust's unsafe blocks do not allow you to dereference NULL (usually the pointer to the memory location 0x00000000). They allow you to circumvent a few compiler checks, including the restriction on dereferencing arbitrary pointers (which could potentially be 0, aka NULL). | |
| May 28, 2020 at 23:11 | comment | added | Mooing Duck | I disagree with "Null is a problem because it's overloaded" specifically because Optional has exactly the same problem. Therefore this is not a reason to prefer Optional to Null. | |
| May 28, 2020 at 7:59 | comment | added | Chayim Friedman | And even rust has unsafe context when you can dereference null. Such contexts are exist (in both C# and Rust, as well as other languages) not to do something you can't with the language, and usually even not to achieve raw performance, but to deal with C-and-similar APIs. You can't call Windows or Linux function that takes a pointer with an Option type. | |
| May 28, 2020 at 7:56 | comment | added | Chayim Friedman | And about validity, if the object access triggers NullReferenceException (or NullPointerException, TypeError, ...) that means unexpected null. This is exactly the situation that nullable types I'm talking about (and Option types, of course) are here to prevent | |
| May 28, 2020 at 7:54 | comment | added | Chayim Friedman | Unsafe code is, ah, unsafe. By design it does not prevent you from accessing low-lever API, and with power comes responsibility. Programmers usually don't use unsafe code, and if they do, they separate it to other classes/modules/packages/dlls/etc.. Also I don't understand why embedded or real-time system can't have constants, especially since compilers nowadays are smart enough to inline compile-time constants when that makes sense. | |
| May 28, 2020 at 7:06 | comment | added | Kain0_0 | @ChayimFriedman True an experienced programmer will use constants when they have the luxury. Embedded systems don't always have that affordance, and neither do high-performance systems that must squeeze (such as the python run time which performs pointer tagging). I also feel you overly discount the volume of inexperienced programmers, and their tendency to prove how much code golf they can achieve. | |
| May 28, 2020 at 6:52 | comment | added | Kain0_0 | @ChayimFriedman Any language capable of call the underlying platform API's, or embedding unsafe access such as via C# unsafe pointer, must be aware of invalid objects, and frankly that includes "modern" languages. But more importantly and to my point validity isn't just a language level concept, try calling a method on a null valued object in C#, what happens? Its a perfectly valid (and defined behaviour) but as far as the programmer is concerned this is an invalid object at this point in time. If it were valid, the call would occur as expected. The null would be valid if an if handled it. | |
| May 28, 2020 at 6:08 | vote | accept | Chayim Friedman | ||
| May 28, 2020 at 6:08 | |||||
| May 28, 2020 at 6:00 | comment | added | Chayim Friedman | <continuation from previous comment> Third reason is just like Option. Cleared and should not be used again - again this is favor of languages like C++ where you can invoke the destructor manually etc.. Magic value - well, third magic value (I can enumerate more: true and false are too many times). There are 0 and 1. And well, an experienced programmer will use constants. Language won't disallow use of ` and 0... | |
| May 28, 2020 at 6:00 | comment | added | Chayim Friedman | Nice. But I'm not fully agree. Uninitialized variables are not allowed to use in modern languages. I can't think a way an object can be invalid in modern languages (in C++ for example it can if the constructor threw an exception). <continuation in next comment...> | |
| May 28, 2020 at 4:46 | history | answered | Kain0_0 | CC BY-SA 4.0 |