"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: https://github.com/mde/true/issues/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.

[kaelonR]

To truly make this library future-proof against the onslaught of frequent changes to javascript's core language features, I think it's probably best if we do not generate the value true ourselves but require the caller to supply it as parameter to the library's public API. The code would look like this:

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

then for users of the library, they'd interact with it like this:

if(aJavaScriptPortOfTheUnixUtilityTrueReturnsTheBooleanValueTrue(true))

This way we can ensure that this library will always work, by offloading the burden of maintenance to the end users and off our own hands.

[Miigon]

@J141 I agree with you but user codebase can also be affected by the frequently changing language, making the library non-functional. I think the best way to tackle this is to train a machine-learning based model to dynamically learn what value "true" should be in a given runtime, preferably implemented without using the "true" value, to avoid bootstrapping problem.

[dandean]

I really like these ideas about future proofing this library. One thing that's certain and has been proven time and again is the reliability and long-term efficacy of the blockchain. If we offload the work of this library onto the blockchain, the value of true will never change, and we can reliably reference it over time, even if the rules of logic and/or thermodynamics are pulled out from under us, like a rug. There are some excellent stablecoins out there we could rely on far into the future, such as $LUNA.

[mde]

Has anyone considered the impact of quantum computing here?

[Miigon]

@dandean One $LUNA as fee for one "true" invoke, sounds like a good idea (AND a great deal!)

[luphoria]

To truly make this library future-proof against the onslaught of frequent changes to javascript's core language features, I think it's probably best if we do not generate the value true ourselves but require the caller to supply it as parameter to the library's public API. The code would look like this:

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

then for users of the library, they'd interact with it like this:

if(aJavaScriptPortOfTheUnixUtilityTrueReturnsTheBooleanValueTrue(true))

This way we can ensure that this library will always work, by offloading the burden of maintenance to the end users and off our own hands.

Seems like a good idea at first, but this opens attack vectors (especially MItM and corruption).

Docker fixes this. What if we shipped a container running Node.js version 12, and relied on this version to define true and then return its response to the user? Perhaps, instead, we could use a complete virtual machine, to combat against potential attacks from or breaking down the line at the advent of quantum computing.

[mde]

Good thoughts here. But there would have to be some way of safely updating the OS/Node versions, as well as whatever version of the container or VM technology we choose. So critical to be forward-thinking in these areas.