DEV Community: Dorla Hutch

Using Loose Equality in JS/TS

Dorla Hutch — Sat, 10 May 2025 15:50:57 +0000

-- Loose Equality allows different kinds to become an equal kind.

I've been feeling, blogposts treat loose equality in JavaScript as a kind of black magic because people do not master it. It isn't supposed to be esoteric magic.

I am not involved in browser development but I conducted my tests with Firefox and Chrome and I read the MDN pages. You can check the examples.

I say, make full potential of Javascript's capabilities, intentionally and knowingly. It can save us from some coding overhead, even when the original definition is sometimes flawed. The loose equality can make code more concise…

This means, if you know the types of the operands. Therefore, the loose equality is particularly useful with TypeScript, because it can show you the types of expressions.

True, even TypeScript lacks understanding of loose equality. TypeScript blatantly lies when it says 0 == [] would always return false (because the opposite is true).

Let's dive in.

Loose comparisons in Typescript

We have two options to use loose equality in TypeScript. 1ˢᵗ We can suppress type checking on operands

const neverTrue: boolean =  0 != [] as any;
if (neverTrue)
  console.assert(false);

or use the "non-null assertion" operator ! on nullable values to turn off errors or warnings while using the loose equality.

Or 2ⁿᵈ, we can use explicit type casts such as

const neverTrue = 0 != Number([]);
if (neverTrue)
  console.assert(false);

Once both sides use the same type, you can just use == or !=. Misuse is hard to miss in TypeScript. TypeScript complains when you are using loose equality not like a strict equality.

For type coercions, Web Devs might know using the (unary) plus + for number coercion or !! (like Boolean()) or ""+ (like String()). You can cast floating point numbers to integers with specific arithmetic operations such as 0 |, -1 &, ~, << 0 or >> 0 instead of using Math.floor(). Coercing Symbols has always ended in a TypeError in my tests.

Note: MDN distinguishes the "number coercion" with + from "numercial coercion" with Number(), because + (only the unary operator) does not work with BigInt. This is a "Big Fail", even the unary minus works! []+ works just the way as ""+ does because [] is coerced to an empty string first.

Summary

For your tl;dr

function equality(a, b)
{
  if (isNaN(a) || isNaN(b))
    return false;

  if (a === null)
    a = undefined;
  if (b === null)
    b = undefined;

  if (typeof a === typeof b)
    return a === b;

  if (a === undefined || b === undefined)
    return false;

  if (typeof a === "boolean")
    a = Number(a);
  if (typeof b === "boolean")
    b = Number(b);
  if (typeof a === "number" || typeof b === "number")
    return equality( Number(a), Number(b) );

  if (typeof a === "string" || typeof b === "string")
    return String(a) === String(b);

  return Object.is(a, b);
}

JavaScript also features BigInts but for brevity I ignore them. We can treat them as if they were numbers which have no comma, infinity and NaN… and no unary plus.

Technically, by definition of the MDN pages, the coercion

first tries [Symbol.toPrimitive](<type-name>) (for objects, arrays, functions)
else tries .valueOf()
else tries .toString()
but two strings will always be compared literally (byte by byte).

Comparing equal types

Let's begin with a note, that Typescript treats == pretty much like === except for ignoring type errors about nulls and undefineds.

== is the same as === when both operands are of the same type, for all distinguished JavaScript types.

This comparison is especially strict among objects, functions and symbols.

Remember: arrays and sets and null are also objects!

Two objects, functions or symbols only satisfy == or === when they are the same! "The same" means, any changes made to one side would also be at the other side of the equation at the same time. In the equation, there is only one single value compared with itself.

undefined has its own special type. null is just an object constant without any properties. (There is only ever one constant null object.)

It goes as far as leading to {} !== {} and [] !== []. Both sides of the equality sign are equal, but separate objects.

Comparing distinct types

This is actually the interesting part where we can avoid writing code.

When I experiment in the browser console with different test cases, this image emerges:

operands of boolean type are replaced by 0 or 1, false is compared as 0, true as 1 (like in C)
- literally it means, booleans inside non-boolean operands (such as arrays) are not replaced.
- I am serious here, false != "false" and false == "0" !!
if one of the operands is a number (or boolean), it coerces the other operand to a number and checks equality again
- probably indirectly by coercing it's string
- note the subsection about NaNs below, any non-coercible thing becomes a NaN (except for Symbols)
- empty strings are 0! Therefore, empty arrays as well.
- values without .toString() either become NaN or throw a type error
else if one of both is a string, it coerces the other operand to a string and compares both
- the standard behaviour boils down to .toString()
- arrays are turned into a comma-separated list of element strings (without surrounding brackets!)
  - unfortunately, these representations are different from the string cast String() and different from the coercion of ==
  - it can be useful for deep-equality of number strings where shape of multi-dimensional arrays does not matter
else, if coercion to a "primitive value" (such as number or string) was not applicable, it compares whether both operands are the same one object. (Functions, arrays and objects won't be equal if not the same.)
- functions of different objects of equal class will be equal; they come from the same prototype
- The equality check will not work with Date objects! Instead, see the takeaways below.
one special type of value, the Symbol, can only be equal by reference (not to numbers or strings)

A careful reader might have noticed that some values cannot be coerced, they don't have a valueOf() or toString(). And standard objects without toString() will throw a type error. But null and undefined are treated as mutually equal and unequal to everything else.

All of this has interesting implications, such as:

[0] == false, "0" == false, 0 == false, [] == false, [false] == "false",
[0] == 0, "" == 0, ".00" == 0, [] == 0, [" 000.000 "] == 0, [[[[[0]]]]] == "0"

but

[false] != 0, [false] != false, "false" != false, [[[[[0]]]]] != " .0 "

Comparing NaN

This is a special case.

No matter what you do, if you ever compare == of a NaN, it will produce a false. != will always be true. It goes completely against the other rules.

Right, NaN === NaN is completely false. But! Object.is(NaN, NaN) ignores this special rule and returns true.

It seems, JavaScript treats a != b as !(a == b) so that NaN != NaN returns true.

It seems contrived that we have to use isNaN() for checking NaNs.
It is rather exceptional that of all things JavaScript follows the IEEE752 standard here, whereas it otherwise violates the mathematical standard semantics of equivalence relations.

Despite that, it is useful to have an absorbing element for equality. NaN originally is an error value in IEEE752. The IEEE task force probably thought, any subsequent computations based on it wouldn't make sense, therefore would result in NaN as well. Starting computations based on NaN wouldn't make sense then and could be skipped.

Relational comparisons

While everybody complains about ==, rarily people seem to notice or point out, that there is no strict version for the other relational comparisons <, <=, > and >=. Typescript checks them as if they were strict.

Comparing Dates, strings (lexicographically) and numbers is pretty straight forward but what happens with a mix of types? It is similar to loose equality but will not compare object references.

Did you know that " 1 " < "1" is true but " 1 " < 1 is false? The first one is compared lexicographically, the second one with number coercion.

NaNs always compare as false (except when using !=).
null becomes a 0, undefined becomes a NaN.

Indeed, ({} <= {}) and [] <= {} is true for some reason but neither ({} < {}) nor ({} == {}) is true. [] >= {} is false as well.

The comparison compares number coercions, otherwise string coercions and it won't compare by reference. NaN and undefined are the special case which always gives false.

null is a special case among the special cases. It is treated like a 0 in relational comparisons. This means 0 <= null && 0 >= null and even null <= [] and null <= "" is true but 0 == null is false!

Symbols cannot be compared with relational operators, it will cause a type error.

Takeaways

a < b is not equivalent to !(a >= b) (you cannot rewrite negations when you have undefined or NaN values)
a <= b is not equivalent to a < b || a == b
a == b is not equivalent to a <= b && a >= b (equality/inequality and relational operators are different things)
a <= b || a >= b is not always true!

undefined == undefined is true but undefined <= undefined || undefined >= undefined is false.
On the other hand, [] <= [""] && [] >= [""] is true but [""] != [].

Booleans generally behave like 0 or 1. Like they do in loose equality.
if you need equality, rather than an identity check, you can make use of a <= b && b >= a
- works great for Dates
- works in specific cases for Objects with custom toString() function
- arrays with only numbers, booleans, undefined and null elements work.
- use JSON.stringify(), it is safer but not entirely safe
  - functions, symbols cannot be turned into JSON and are like "erased"
  - BigInts cause an error
  - the order of object properties can be non-deterministic
- ultimately, a 3rd party library such as lodash is required for equality checking of objects
- does not work with arrays whose elements have commas , in their string representation
- nested arrays are not visible in the relational comparison
relational comparisons of Symbols will crash your script

Outro

Anything written here is meant for the good of others. If you know something better or something is awry, leave a constructive reminder in the comments.

The (un)inuitive meaning of "inline" in C

Dorla Hutch — Sat, 03 May 2025 03:10:21 +0000

+-------------------+
|  + - - - - - +    |
| x I N L I N E y z |
|  + - - - - - +    |
+-------------------+

Effectively, the inline keyword in C turns a definition into a declaration, and serves to move the function body to the header file.

Actual meaning of the inline keyword

inline turns actual definitions pretty much into forward declarations. inline definitions are shared in the header and the declaration (indicating the fallback implementation) goes into the implementation file. The non-inline declaration implicitly reuses any other definition in the same file and therefore turns into the implementation.

Conversion into inline functions

Converting functions into inline functions is easy: move the body from the implementation file into the header file and replace the extern with the inline keyword at the destination.
(But consider the annoying refactoring overhead which only makes sense for significant performance gains. If your function is never inlined or inline is undone later, it was in vain.)

Before:

// file.h
int square(int x);
// file.c
#include "file.h"
int square(int x) {  return x*x; }

After:

// file.h
inline int square(int x) {  return x*x; }
// file.c
#include "file.h"
extern inline int square(int x);  // "extern inline" is optional

The non-inline declaration doesn't even require an extern , because non-inline function declarations are extern by default. extern inline can also be used in the implemention file to emit a function from the definition.

I believe, there is no effective compilation difference between extern inline and extern except for expressing with extern inline the intent that other coders should search the header file for the definition. (Not sure, if there is compiler-dependent semantics.) GCC seems to make no difference between them. But you need to turn optimization for GCC to inline functions.

`inline` as assertion

Without an extern declaration, the inline asserts inlining of the function, i.e. compilation is made to fail if the compiler doesn't freely choose to inline it. (E.g. it enforces compilation with optimization or fails ultimately when the function cannot be inlined.)

Original problem

Interesting is, what is the sense behind this specification of the C committee? (Besides technical limitations such as C's translation units.)

It seems, the original problem was not to annotate functions as "inlinable". Functions are inlinable when the compiler chooses to inline them, independent of a keyword.
But! It can only do so (in C) if it knows the definition. Since function declarations in the header lack a body, they cannot be inlined in foreign files. The only purpose of inline is to use a function body that does not emit a named function, allowing for a function body in the header file.

inline rather means, a body is inlined in the declaration, rather than at the call sites.

History

Previously, the GCC compiler defined extern inline what later became inline in the standard. It made sense to think, that anything in headers should be extern. The C committee apparently had a different notion of extern, indicating that it is only type information and not the associated (function) definition (which could be the same or a different file).

Extern declarations weren't even required before C23. Not providing them would just omit type checking for unknown functions (with warnings) and assume integer return type.

Therefore, extern did not express that the function is in a different file (this would be assumed automatically) but provides typing for the current file (that is sufficiently distinct from a definition). And if we have a definition (the inline definition), we still need an actual signature (declaration) to automatically a emit a function in the current file.

Using `static inline`

Finally, there is also static inline. If your compiler really treats all functions with known body (and suitable preconditions) as inlinable, then a static inline function would be just a normal static function.

After all, people likely use static inline when they believe to increase the inlining probability by doing so. (This maybe could depend on the compiler.) Unless you know that, it might not be worth using static inline. In return, there is a risk that every file which does not inline every call of it will create a copy of this function in that file. In big projects, this could lead to a lot of code duplication even with 90% inlining.

A better probability for inlining is obtained for writing small pure functions. (Especially when passing compile-time known values to it.)

In most recent GCC, static functions can silently be removed from the source code (with optimization turned on). In contrast, this does NOT happen with extern (including extern inline) declarations which always emit the function even if unused.

This means, if your static inline header function is always inlined, then static inline is as good as inline or static without an additional extern declaration. But if not, you get no linker error but code duplication in the linked binary, when using static (or static inline).

static inline indeed ignores extern declarations which follow after it but will not tolerate when they precede it.

Enforcing function inlining

And if you really need to enforce inlining, you need to use a compiler feature such as __attribute__((always_inline)) in GCC. It cannot inline every function (for example when a function pointer is used) and could fail to compile in such a case but it will try harder.

Anything to add or correct? Let me know.

Most people understand Referential Transparency wrong

Dorla Hutch — Thu, 31 Oct 2024 00:26:13 +0000

(Image from Stefan Alfbo's Post)

What do you think of when "Referential Transparency" comes to your mind? Perhaps you are thinking about purely functional programming languages. But People who think of it only this way, do not have a complete picture of referential transparency.

———

Conception

I have been browsing Stack Overflow and found no satisfying explanation about it. For me, it's no surprise that I know of no language which allows for expressing real-time and system-programming behaviour in a referentially transparent way.

Usually, referential transparency (in programming languages) is seen as a subset of expressions or functions whose result value can be replaced by a constant value without changing program semantics. Coders believe, it is necssary to constrain themselves to obtain referential transparency. They think of functions which do not have side effects. While this is just a special case of referential transparency, this is not a necessary constraint.

Here is, how I understand Referential Transparency:

Referential transparency is a property of a type system. With referential transparency, the system offers types whose element values can be used to replace any specific language expression without causing a change in the language's specified execution semantics.

———

What we need for referential transparency are values that can convey execution semantics (as much as they practically matter), including side effects.

This means, we could have a referentially transparent OOP language if the type system would be complex enough and permits type checks.

Code blocks or thunks would be values of such types. We could specify a parameter type to expect a value whose semantics does not alter shared variables. Or specify that a parameter value calls a function or writes IO a given number of times in a specific order (a side effect iterator of some kind).

Truth is, purely functional programming languages have side channels and side effects too but they are deliberately omitted from the language's semantics specification. If not optimized away, function calls have time and memory cost. Leaky Abstraction is another catchphrase for this issue which occurs when internal details are excluded from the public specification of abstractions. They produce effects that cannot be explained within the simplified specification of the language. Information leakage is due to incomplete explanation of the abstraction, not due to the abstraction itself.

Referential transparency is not a property reserved to functional programming. The problem just is, other popular languages are not trying to enhance their type system in adding side effects to their type checking.

In comparison, if we ask a competent human being, the semantics of programming code is sufficiently transparent (even when it needs compiler- and computer-specific knowledge). If we ask a competent developer to refactor code into a method call, they are able to do it (if anyhow possible). With improved types, programming language interpreters could refactor code for optimization purposes.

Global variables, (real)time, space requirements or other system functionality (IO, storage access and system calls) are typically considered to be side effects (technically, memory access is also one due to modification of caches). But, they are mainly called "side effects" because that stuff is not modelled in the type system.

———

Referential Fallacies

Referential transparency arises when semantics is a closed system. In natural language however, words generally have multiple or contextual meanings and may dynamically change over time, the expressed intension might even differ from the words' direct meaning, like in idioms or ironic statements.

If two things are equivalent, they can be exchanged and it will not alter the meaning. Referential opacity is the case where words are not equivalent even if they share a reference to the same entity (linguists say "co-referential").

Example time. If a person has two names "Al" and "Bo" (of course I mean Alex and Boris, what were you thinking 😉?), these names are not equivalent. The expression "A name of Al" has even multiple meanings (it could be "Al" or "Bo" or both). If we use "the" as in "The name of Al", we are refering to something that mathematicians call a "principal value". It produces the same meaning as "The name of Bo". (I interpret it as "The [principal] name of Al".)

The reason, why "Al" and "Bo" are not equivalent is, because words are more than one reference. They also refer to themselves as a name entity in a second meaning. (Disambiguating the meaning is subject to a context.) The sentence "Al begins with an 'A'" shows the second referential meaning of "Al": the reference to itself as a name object. In that regard, "Bo" is not equivalent because when "Bo" refers to a name object it's a different one with different letters, even if both names have the same referent (in a temporary context!).

Let's take a case from a popular animation show: assume, "Ladybug" is a cover name of "Marinette" and there is a boy "Adrien" who does not know of "Ladybug"'s true identity. We know that "Adrien loves Ladybug". Is the proposition referentially opaque because "Adrien loves Marinette" does not hold? No. Objectively seen, it is still true, because "Marinette" and "Ladybug" may refer to the same person and Adrien just does not know it. Subjectively, if Adrien would be asked about it, he would probably say yes or no to the second statement, because he doesn't know the truth. (This is certainly the notable part early in the show, that a real perception of (no) feelings doesn't have to match its actual truth.)

With another argument, Ladybug has her own skills and personality aside from Marinette. Both names do not have the same meaning and so the meaning of "loves Ladybug" and "loves Marinette" really is a different one. The previous argument would hold however if we had two names which are exactly aliases, not differing in context.

———

The previously mentioned Wikipedia article also claims _ lives in _ (e.g. She lives in London.) were referentially transparent and _ contains _ (e.g. 'London' contains 6 letters.) were referentially opaque. Both does not hold in general, there is no referential transparency property for natural language predicates. It is the verbatim context (characters appearing inside a string) which makes the quoted part of the sentence referentially opaque. Of course I can correctly say "The name of London contains six letters." (or the name of England's Capital) and I can say "She lives in 'London'" (but not "She lives in 'England's Capital'").

Does this mean, code inside string quotes is referentially opaque? Not in general. Funny thing is, did you know that Mr. Quine also is the one who came up with the idea of string interpolation in logic? (He called it Quasi-Quotation, using ⌜…⌝ as quotes.) Because in the context of string or code interpolation, we can make string contents referentially transparent.

Check out this case of referential transparency: She lives in ⌜{_}⌝ or ⌜{_}⌝ contains 6 letters. (We can use London and Capital of England at the same time.)

Typically, referential opacity occurs with words which are co-referential in the limited definition of a typesystem but not sufficiently close to the typesystem in the actual meaning.

———

Prospect

Why after all would it be a problem to think referential transparency as only side-effect-less functions, if it works?

Because side-effects matter in practical software, the ability to hide extraneous mechanical details with side effects can reduce reading and writing overhead. The rejection of side-effects can limit expressivity. One consequence of the view of "referential transparency → no side effects" is, strictly referentially transparent languages (that I know of) have no realtime semantics (Haskell only has one for debugging purposes).

Nothing prevents us from defining types with time, space or other side effect semantics. A value with a duration of 3 seconds could be interpreted as a busy waiting loop with a sufficient number of instructions when it takes effect. A value can have a sequence of certain effects as properties, such as IO, memory operations or memory constraints. This means, we could specify allocation regions as part of a type. These "effect values" only need to be first-class citizens and can also be combined with other values.

An impediment could be, it makes type checking more complicated. A future-relevant language should make an ideal specification and treat realization as a research challenge. Maybe it isn't decidable in 100% of the theoretical cases but why not still permitting types for the cases that practically are decidable by a resource constraint? It does not sound plausible to me that someone actually needs code in practice which must have undecidable semantic properties. Practical software usage is bounded by limited resources. Code which exceeds specified resource limits of time and memory is unacceptable.

This is the end of my monologue for now. You think I confused something? Let us know in the comments.