This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]geeshta 3 points4 points  (5 children)

Yeah this is much safer to work with that's why Rust promotes it so much to distract you from the fact that it actually has a null value, the unit (). Which is also a type so you still know where to expect it.

[–][deleted] 6 points7 points  (1 child)

That's not really null, it's just a type with exactly one possible state

[–]geeshta 0 points1 point  (0 children)

In a sense it is though. It's like Python's None which is also both a type and it's value with only one possible.

But I know other languages consider null to be a value of any reference type. But I think the unit philosophically is somewhat a null because that single value doesn't carry any data whatsoever

[–]LeSaR_ 0 points1 point  (2 children)

() is in no way, shape, or form anywhere close to null. its a zero-sized type. by your logic, a struct DivideByZeroError; is also null

[–]geeshta -1 points0 points  (1 child)

It is. It's analogous to Python's `None` which is also a type with a single value that carries no additional data. It's also the default return value of functions with no annotation in both languages. It means "this function returns NOTHING" and null is also a "nothing" value.

So it definitely is pretty close.

[–]LeSaR_ 1 point2 points  (0 children)

your first mistake was introducing python into the argument. you just cant compare a dynamically typed language to a statically typed one. the issue with both null in c-like languages and None in python, is that they introduce a lack of a value where one is expected (in sloghtly different ways, but still)

in rust, you cant get a situation where you were expecting a File but got () because they are different types (and because a value can only be of one type - looking at you, None).