[tobr]

The `in` operator always returns a boolean, though.

[reaperducer]

Maybe it was just done out of habit.

A bool can be expected today. But why about 10 years from now? Defensive programming isn't a bad thing. Making assumptions is why we had the Y2K mess.

[mark_and_sweep]

That's an unreasonable, excessive use of defensive programming.

We're not talking about an unstable API here, we're talking about an operator.

It would be just as unreasonable to "defend" your code against `1 + 1` suddenly returning a boolean rather than a number.

[Raphmedia]

You already know that ìn` will return either `true` or `false`. Why use `==` which will convert data instead of `===` which will test for a boolean directly?

Ignore the symbols and use the words. Which makes more sense to you?

"[My test] strictly equals true." or "[My test] loosely equals true."

[wereHamster]

This looks future proof to me: `if (JSON.stringify("something" in foo).match(/t/) != null) { … }`