That's not really true. Code contracts are just a library , it's certainly not "traditional" in C# to use that to check for invalid state. Traditionally you just check the value before assignment. And if you do this your entire problem "goes away".
Gotta say this is one of the most contrived "F# is better than C#" example i ever saw.
I wouldn't say spreading null checks and forgetting them all over your code makes any problems "go away".
I remember when HN wasn't /.
The article tldr: Poor design is poor design.
Edit: Please, HN, do continue to prove my point. Idiots love their little echo chambers.
Assignment checking is pretty simple but would not work if you want to verify the correctness of the program in compile time. Which you can still do just fine in C#.
You would use a class hirarchy with a `User` abstract class and `ActiveUser` and `DeletedUser` subclasses and use the type system to enforce the constraints. The syntax wouldn't even look worse.
If we're talking about a functional style then yes, `User`s would be immutable object, changing them would return a new user. Doing `activeUser.Delete()` returns a new deleted user, doing `deletedUser.Undelete()` returns a new active user. I might go as far as creating the user as a value type (struct) but that's a bit unorthodox.
But don't you now risk having two mutually contradictory objects representing one user?
Think of the following code:
if (n != null) {
n.do_something()
}
So you are already assuming that you can do certain things atomically, even if, in theory, some external agent can write on your data. You manage that by protecting your data (with asynchronous tools or immutability), or by statically verifying your code.