622
submitted 11 months ago by jroid8@lemmy.world to c/programmerhumor@lemmy.ml
you are viewing a single comment's thread
view the rest of the comments
[-] dukk@programming.dev 7 points 11 months ago* (last edited 11 months ago)

I’ll point to how many functional languages handle it. You create a type Maybe a, where a can be whatever type you wish. The maybe type can either be Just x or Nothing, where x is a value of type a (usually the result). You can’t access the x value through Maybe: if you want to get the value inside the Maybe, you’ll have to handle both a case where we have a value(Just x) and don’t(Nothing). Alternatively, you could just pass this value through, “assuming” you have a value throughout, and return the result in another Maybe, where you’ll either return the result through a Just or a Nothing. These are just some ways we can use Maybe types to completely replace nulls. The biggest benefit is that it forces you to handle the case where Maybe is Nothing: with null, it’s easy to forget. Even in languages like Zig, the Maybe type is present, just hiding under a different guise.

If this explanation didn’t really make sense, that’s fine, perhaps the Rust Book can explain it better. If you’re willing to get your hands dirty with a little bit of Rust, I find this guide to also be quite nice.

TLDR: The Maybe monad is a much better alternative to nulls.

[-] Feathercrown@lemmy.world 4 points 11 months ago

Isn't a Maybe enum equivalent to just using a return value of, for example, int | null with type warnings?

[-] itslilith@lemmy.blahaj.zone 2 points 11 months ago

Not quite, because the Maybe enum is neither int nor null, but it's own, third thing. So before you can do any operations with the return value, you need to handle both cases that could occur

[-] Feathercrown@lemmy.world 5 points 11 months ago

Isn't that also true with compile-time type checking though? Eg. 0 + x where x is int|null would be detected? I don't have much experience here so I could be wrong but I can't think of a case where they're not equivalent

[-] itslilith@lemmy.blahaj.zone 4 points 11 months ago

Most languages that let you do ambiguous return types don't do compile-time type checking, and vice versa. But if it's actually implemented that way, then it's logically equivalent, you're right. Still, I prefer having things explicit

[-] Feathercrown@lemmy.world 1 points 11 months ago

Yeah it's nice to be able to see it

[-] kogasa@programming.dev 3 points 11 months ago
this post was submitted on 08 Dec 2023
622 points (96.4% liked)

Programmer Humor

32549 readers
478 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS