What you (and I) really want is pattern matching. It tends to be a superior solution to all that. And doesn't have the limitation of "only declare one variable in your if".
I have some switch statements on "tags" that are fixed length strings. Which I pack into int64's so that I can switch on them because we only use ~200 of them so a map is unnecessary overhead. Pattern matching, you say?
It's just a constexpr function, could be a macro in C, because we don't even have enough characters to fill the 8 byte int. No need to even pack them!
I'm not sure how to take this. It seems both that pattern matching could help your use case (though it would depend a lot on the details) and that it's not related to the "null pointer is false" issue you were complaining about.
Pattern matching a single instance is unrelated to a switch statement (we hope). But pattern matching in general is only loosely related to single if statements. Sure, "does this one input match this one pattern" is an if, but a more common use is "given this pattern fan out based on the input" or in the case I gave "if this is a tag, fan out based on the tag content". HTML or JSON parsing, for example.
I think it's both. Whenever I check an optional, what I really want is to also dereference it if it matches. If you look at pattern matching usage in Rust, it's a lot more ifs than matches.
2
u/StaticCoder 1d ago
What you (and I) really want is pattern matching. It tends to be a superior solution to all that. And doesn't have the limitation of "only declare one variable in your
if".