I found something interesting about non-English characters and how they are searched & matched using CF function https://trycf.com/gist/f9444ec0e0237046e484a520e64bc717/lucee5?theme=monokai So in some versions of Lucee & ACF, ASCII char #383 (which is " ſ ") is the same as English letter "s" & "S" (yes, it matches both lower case & upper case)

(me again, posting from my personal account) Testing chr(383) eq chr(83) - upper "S" ==> true Testing chr(383) eq chr(115) - lower "s" ==> true https://trycf.com/gist/449b2aa9fba7085493b0d63fd194a172/lucee5?theme=monokai From tryCF.com; cfml engines saying chr(383) eq to "s" / "S" • Lucee 5 • ACF 11, 2016, 2018, 2021, 2023 cfml engines saying chr(383) neq to "s" / "S" • Lucee 4.5 • ACF 10

FYI BoxLang returns false for

echo( char(383) == "S" )

See what this line does instead: (note the case-sensitive nature):

result = Replace(test, "#chr(383)#", "_", "all");

https://trycf.com/gist/c3f61f154fafe0ccab4c7e1940d6e4c0/lucee5?theme=monokai

Yes, I noticed if using case-sensitive search then VSCode won't match chr(383) to "S" & "s". And we indeed changed our replaceNoCase() to replace() when substituting these characters. Thanks for the link to that chromium ticket. I didn't know there are so many characters behave the same in Chrome. And yes I agree Chrome needs a case-sensitive search likes Firefox, so ppl using these languages & characters can control how they want to do text search

I would submit a bug report to Lucee for 5.4.6+9. That’s a breaking change that would effect any kind of UTF-8 string comparison

It seems to behave the same in all of them

I think there might reasons that ReplaceNoCase(text, chr(383), "_", "all") replacing all "s" & "S" with "_" ? As per the article I posted earlier, chr(383) is letter S; but it is not lower case "s" nor it is a upper case "S". That's why Replace(text, chr(383), "_", "all") won't replacing any "s" or "S" But the case that chr(383) == chr(83) and chr(383) == chr(115) I would consider that a bug.

I think it has to do with how ascii works when you mix it with extended ascii kinda?

asc(test_S) == asc(test_s) --> true

this is my bad, I was naming the variable

test_S

and

test_s

thinking CF supports case-sensitive variables. But

"s" == "S" --> true

is new to me. I have always thought string equality test is case sensitive and always do this

lcase(var1) eq lcase(var2)

😅 Guess I should always test, don't assume, even as simple as this

LOL & OMG! I totally forgot that variables are case-insensitive as well! If I had been running a good linter on it, maybe I'd have been alerted to that common mistake! 😉

There's always been

compare

and

compareNoCase

which has been the recommended way of comparing strings where casing matters. CFML has always been positioned as a case-insensitive language, so there should be no surprises that the equality operators behave that way. As for

===

behaviour, I believe Lucee's implementation is bugged in its design (as well as its incompat with CF) in that it's doing an identity check, not following the CFML rules which is "check type then check value", where in the case of strings "check value" is case-insensitive. Compare: https://trycf.com/gist/f66fdce2282956978e67f50edf9ac430/lucee5?theme=monokai When using string literals, the strings will equal due to how Java stores string instances; but if the values are created dynamically,

===

is no help to you.

Good point about Lucee's being an identity check! I think they took inspiration from JavaScript. Is there any way to check that the object is the same in Adobe's version? FWIW if I'm thinking "strict equality" then I'm thinking "S" != "s" and although Lucee's version has its own way of footgunning you, I like it better than the Adobe footgun. (Also, if a feature has been in Lucee for years, and then Adobe adds it, I personally think it would behoove Adobe to make their implementation compatible with Lucee's. But I digress.) I like the logic on display here! It's a valiant argument for Adobe's implementation, but I don't think it is a strong one, since it's supposed to be "strict", and if case-insensitive is "strict", it makes my joke of

====

not so funny (like what would be a shorthand for stricter-strict equality?) There's a reason JS added

===

, and I think it's the same reason CF needed it (dynamic types), so of the two implementations I'd take Lucee's, as it's closer to filling the actual need.