"true" should not be hardcoded

[throop02]

If the ES standard is updated and "true" is changed to another keyword (such as yea, yes, or affirmative) it would break this library. Instead of returning true could we return (1==1)?

[yukulele]

or simply (NaN !== NaN)

[mde]

In theory, the ES standard could update the definition of NaN, or even 1. Can we think of a more future-proof way to accomplish this?

[mde]

Also worth noting that the strict equality operator is not necessary with NaN. No value is coerceable to be equal to NaN -- not even itself.

[tfrijsewijk]

return !~-1;

Perhaps then we should look into #7 caching again

[mde]

It's also theoretically possible that the laws of logic could change, and this could no longer be true. Ideally we'd find an even more bulletproof way to represent this.

[solonovamax]

Perhaps we could try calling the unix tool true from the command line? I hear that it's pretty fast & accurate most of the time.
Though, that means you'd need some other method for non unix systems, or unix systems without true.

[OlegGavrilov]

Perhaps we could try calling the unix tool true from the command line? I hear that it's pretty fast & accurate most of the time.
Though, that means you'd need some other method for non unix systems, or unix systems without true.

I would rather depend on a wasm-compiled version of true tool.

[Miigon]

just in case the fundamental law of thermodynamic changes in the future, how can we think of a better/more future proof way to build a computer on which this library runs on?

[mde]

Any serious effort here needs to take all the various Quantum Computing models into account.

[devshark]

Have we considered the following?

return !undefined;

I am assuming undefined will never be defined, and it is guaranteed after the announcement of IE's retirement.

To be completely safe and backwards-compatible, we can define our own undefined value:

module.exports = function aJavaScriptPortOfTheUnixUtilityTrueReturnsTheBooleanValueTrue () {
  return function (undefined) {
    return !undefined
  }();
};

[mde]

This could be an interesting approach, although conceptually this is relying on JavaScript type-coercion behavior, which seems less strict than the rigorous and obviously hugely beneficial typing approach conceived of here: #25

[devshark]

I've updated the PR and skipped type-coercion altogether.

return undefined === anotherUndefined;

[TimVosch]

Wouldn't it make sense to have a serverless function somewhere which this function references? That would also help horizontal scaling if a project requires a lot of true's/ye's/yes's/affirmatives's.
You wouldn't have to bother about the definition of true since the serverless can simply be update by a third party.