Compatibility Idea: IS and ISN'T replacing == and !==, not = and <>


I think it's untenable that == and != are in the language, but not a pairing (the complement to == is !==). And I've said that == does not look literate, it's too much like a divider.

What I had proposed was having = take strict equality, and is taking lax equality. The wordishness of is made its fuzziness seem more appealing, and that appeal would be probably to the types of people who would like laxness in their comparisons. Those who prefer the symbol might (?) prefer strictness as a default. (This is a hypothesis, not tested.)

But having written Making the Case for Caselessness, I argue that case insensitivity has some legs. Maybe enough that we need not be ashamed to have = be a "lax" equality operator, in the sense of comparing case-insensitively...anyway.

Which raises a question. What if is and isn't were the strict equality operators, and =, !=, and <> remained lax?

It still kills off == and !==. And it's much more compatible with history. With this being used implicitly as the comparison operator in things like FIND and such, it can be argued that laxness takes primacy for the = symbol.

All things being equal (ha ha), I would probably prefer it the other way around. Math explains what "equality" is, and it doesn't have a "stricter" form. But "is-ness" is something more vague to define.

But there's code and expectations out there. So perhaps this is the way to go. Once you've taken == and !== out of the picture, I think it may become one of those too-close-to-break-even changes. And Beta/One philosophy is that we just stick to status quo in that case.


When I looked at the examples on chat, this way looks much better to me.


Looking at how it reads, is seems to imply an exact match more than =, i.e. "to be or not to be" that thing being compared to.


It's hard to say whether I'd see it that way if I were looking at it from first principles or not.

Given that I can't really tell, the path of least resistance is to keep = lax, make is strict.