Is that Rust? Assuming a is an Option (which would be close approximation of OP’s nullable type) and assuming b is not null, then this would be closer to the original idea:
a.unwrap_or(b)
It returns value of a if it’s not None rather than Option.
Theoretically, it was supposed to be pseudo-code, secretly inspired by Rust, but I did get that one mixed up.
And I am actually even a fan of the word unwrap there, because it follows a schema and you can have your IDE auto-complete all the things you can do with an Option.
In many of these other languages, you just get weird collections of symbols which you basically have to memorize and which only cover rather specific uses.
I enjoy this:
But yeah, that requires an
Option
type rather thannull
pointers…Is that Rust? Assuming
a
is an Option (which would be close approximation of OP’s nullable type) and assuming b is not null, then this would be closer to the original idea:a.unwrap_or(b)
It returns value of
a
if it’s not None rather than Option.Ah, true. Thanks.
Theoretically, it was supposed to be pseudo-code, secretly inspired by Rust, but I did get that one mixed up.
And I am actually even a fan of the word
unwrap
there, because it follows a schema and you can have your IDE auto-complete all the things you can do with anOption
.In many of these other languages, you just get weird collections of symbols which you basically have to memorize and which only cover rather specific uses.
a?.or(b)
Kotlin go brr
a ?: b