ISSOtm
Support `===` and `!==` for strings
This is viable now that EQUS expansion will be removed, and I would find p == q much more clear than !strcmp(p, q). We also already have the ++ operator for strings.
// Note that they are only excluded when not part of an expression, since e.g. `this + that` is unambiguously a numeric expression, // and `this ++ that` is unambiguously a string expression. // (This does mean that the set of infix operators used for each expression kind must be distinct, but that's fine.)
Does this mean we can't actually support "a" == b" and "a" != "b"? We could still have string-specific === and !==. (Perl has eq and ne as string-comparison operators (plus many more), but let's not copy that.)
I think not. Maybe you could specifically exclude leading symbols from the offending operator branches and then handle them specially in StringOrExpr, but I foresee combinatorial explosion and/or a lot of code duplication, so I'd rather not.
Specific operators would work, but === already have string-valued semantics in other languages, so I'm not sure they specifically are a good idea.
What "string-valued semantics" does === have in other languages that would make "foo" === "bar" for value equality confusing in RGBASM? (It would mean the same thing in RGBASM as in Javascript.)
No, I mean that people would be surprised that === doesn't work on expressions.
Hmm. Maybe so? But they could also be surprised that 2 ++ 3 doesn't do something reasonable. (Or get confused with C and expect n++ to increment n.)
If we can't support both 2 + 2 == 4 and strupr("a") == "A", then I'd rather have string-only strupr("a") === "A" than have no operator at all. Unless there's some better way to spell a string-comparison operator? =~= and !~=? 🤷♀️
We could make it ~= and !~. But that would incorrectly lex someone writing !~1, e.g. !\1 with m ~1.
Then I still think === and !== would be the best choice; they share the "one extra punctuation for string op" aspect with ++.
Implemented === and !== in https://github.com/gbdev/rgbds/pull/1832, since parsing them doesn't actually depend on removing EQUS expansion first.