The result of anything you interpret undefined as is undefined(not defined) and the equality of that value to any other value is also undefined(not defined).
1&2. It may always be true, always be false, and(sic) sometimes be true. The ?u32 you receive has no meaningful value and it is undefined to branch on.
Undefined is not the same as null. There are better explanations, but the way I understand it is that when the variable is set as undefined, the caller must guarantee that it had been set prior to using it.
My understanding is that when you set a variable as undefined in Zig, you are basically saying “I’m creating a variable, but it has no meaningful value yet”, and you must give it a meaningful value before using it.
However, I’ve wondered how, if at all, you can represent JavaScript’s version of undefined in Zig, where undefined means “this value has not been explicitly set.”
This usually gets used for:
unset variadic arguments in function calls.
key accesses on objects, where the key isn’t present.
As a subset of 2, when loading for example, a config file, any key you read as undefined can be presumed to not be set, and therefore you can use a default value instead, whereas if you see a null, you can assume the user wants it to be empty.
1 and 2 aren’t applicable to Zig, but I feel like 3 could be, although it’s a definite edge case. It is sometimes helpful to know whether foo.bar is null because the user set it to null, or whether it’s null because it was never configured.
There are frictionous ways to do this in Zig and perhaps that’s how it should be.
Yeah, that is a perfectly legitimate use of a double optional. But surely the question marks have to end sometime…
const std = @import("std");
pub fn main() !void {
var cmon: ?????u64 = 1;
std.debug.print("{}\t{x}\n", .{ foo.?.?.?.?.?, std.mem.asBytes(&foo) });
std.debug.print("Just cause you can, doesn't mean you should XD\n");
}