Here's my thought : The Curious Case On The Use of Option<'T> / null

[Xyncgas]

Very often we run into Option<'T> / null
both None, null, represent something that doesn't exist

I think I've heard some amount of discussions around this matter, such as f# is better because it doesn't have null, such as null is a billion dollar mistake, such as sometimes you still need null to represent something invalid or missing

It's a single value, that's representing, either something gone wrong or something is missing

if your method is returning null, it's likely whatever gone wrong was encapsulated in the method, therefore for you getting a value. if you had side effects in the method that gone wrong and you returned null well something might explode or you threw an exception before doing anything in the method and you are safe because now you can handle the exception and maybe you would then decide yup it's doomed and choose self-destruction -> exit the program -> yet it is still infinitely better than say writing the wrong thing into the database

now in f# we say we build expressions and there's no side effects in the function, we do still have side effects, because at some point maybe at an inappropriate place or maybe eventually we might need to do something, like writing something to the database. so there's also two places we can be looking at the optical scope where null/none can be returned : functions that has no side effects (pure functions in the expression composition) & functions that has side effect.

Now before we are moving forward and look at these cases, I would like to remind ourselves why is it that we have to deal with these values, why can't we just delete null from the language and we never have to deal with them again.

Invalid State.

If you started a program with a valid state, and everything you do is 1+1 then obviously there wont be anything wrong. yet if a program is guarrenteed to run forever in valid state on its own, there is no other guarrenteed to the program, say for example the cosmic radiation hit its memory and flips a bit.

if external factors are introduced into a valid state, well now it might not be valid. Most oftenly, it's by user interacting with the software

it might still remain intact, although sometimes consider :

let FindSomething (Selection) =
    //...
    if Found then ...
    else ...//what if didn't

People, a pure function simply maps the input to the output with its logics, we can provide the correct input to return the valid output. yet we have to deal with people, that's when we can't guarrenteed it's the things we need unless the constrain of valid input of a function is also defined as any by the nature of the function (e.g AI training)

Now if we recieved null and we are still computing things we can just pass the value on, or optionally we don't care or do nothing and that can be fine

Yet sometimes at some point we must face the fact that we've got null in our hand, it's like a hot potato. in other words, it's a value that should absolutely not be nulled, then the people panic and the kernal panic and the business panic

Because well some method or some operations specifically says they don't accept null or Option.None or any other invalid values, you can choose to do nothing with condition checks and validations and guards, the problem is a program was design to do something and you just absolutely have to deal with it or it's not working anyways. Maybe you can save the UI for it to be responsive, maybe it won't, it depends on what people interpret the state of the program now

Perhaps all invalid states are valid states, because assuming it wasn't the developer who caused it but the user who did, we can pass the responsibility back to the person that's interacting with the program and introduced the external state into the system

However it's frequent that we don't want to piss off the user, who just want things to work, it's reasonable.

So now it comes down to, can we do better when user did something to the program, say entered their passwords or pressed button.

If the input absolutely is unacceptable for the program to do its job, we just don't do the job but don't panic and keep everything in order and don't break the UI's responsiveness, this's damage control

If we can even find a way to make work with the job the program is supposed to do, that's better.

The invalid state however once introduced it won't be gone, you may have done damage control you may have carried on, but it will always reflect back on, either they want you to confirm the email address later, or the video player shows artifacts

We have come a long way

As a developer, to be mindful of how everyone feels, has to, or suffer in chaos caused by unmindfulness, people will, therefore not by running away but face it we shall

[huoyaoyuan]

It's a single value, that's representing, either something gone wrong or something is missing

This is not how null being used at all. "Nothing is associated" is clearly a valid state for many scenarios.

Null doesn't come. It was there until you fill something other.

I don't like to talk about null solely. It's just a form of default. While you can override default value of simple variables while allocating its storage, it's much harder when there come containers like array.

Also note that C# is a language somehow closer to ABI. The compiler doesn't do complex transform to store the states. null is the state of allocating storage for reference types. C# does expose the raw allocations.

I think the most important thing next is to track the default-able state of structs. This fulfills the diagram with NRTs.

[333fred]

What's the language request here?

[333fred]

Even show & tell should be related to C#. This doesn't seem related to C#, and would be better served being on a blog.

[Xyncgas]

2 more Maintainers out here having the same opinion as you, I will think about it a little bit more
I assume you won't ban me for saying this, you need to have a better / enough reason than "I think.. it seems..." are you sure you are just not inserting yourself too much into things which I understand it's your job and so is thinking about what I just said, otherwise if one person walking around policing people without a valid reason I am pretty sure it's called a police state in real life and freddy do you want to live in a police state where police walk around and beat you up because you wore the wrong cloth or said the wrong thing

I am hoping that when people are asking me to comply, they are going to give me something which we as a society can talk about it in the open and see what's right and what's wrong, or you won't have to worry about telling my post in "show and tell" topic that it's not related to C# because I think you were drunk and that's OK and you just won't see me here anymore

[HaloFour]

You're being asked to make this a relevant discussion about C#, not some random rant on the state of programming in general. There are better venues for the latter. The maintainers of the language are not required to offer you a soapbox on this repository on which you can write anything you want. Off-topic content can and will be moderated. If you don't like that you are free to go elsewhere.

[CyrusNajmabadi]

I'm genuinely not certain what this topic is about. Perhaps you'd be interested in coming to discord.gg/csharp to chat with people and to see if there's are ideas to distill out that could maybe return here? Thanks!

[jnm2]

I like the idea that discussions could happen here under a more general umbrella than the "language ideas" category we have for suggestions.