I also missed the awesome bind-operator. EG:
const getFoo = () => this.foo;
const bar = { foo: 1 };
console.log(bar::getFoo()); // 1
https://github.com/tc39/proposal-bind-operatorI also missed the awesome bind-operator. EG:
const getFoo = () => this.foo;
const bar = { foo: 1 };
console.log(bar::getFoo()); // 1
https://github.com/tc39/proposal-bind-operator +value|0
There's also TypedArray [0]. I think you'll be interested in the BigInt proposal [1] [2], which is stage 3. It's already available in Chrome, and behind a flag in Firefox. Now that it's possible to accurately represent 64-bit values, we're getting BigInt64Array and BigUint64Array.[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
You would need to use `function` for this:
function getFoo() {
return this.foo;
}If you're putting getFoo at whatever level of scope that you'd run it over multiple bar objects that don't have it bound, why is it conceptually different than writing it as
getFooOfBar(this_bar:hasfoo) => this_bar.foo
(If you get my drift from the terrible notation; and you could drop the type-safety and just take an any obj if we're being more literal to your pseudocode)I had honestly not seen the bind operator used in at least the last decade, so perhaps the dissonance is just whatever corner of tech I work in having a distinct style/idioms.
Why exactly do you want that? Is it arbitrary precision you want? Is the 56 bits or whatever not enough for your use-case? Or do you find the range checks are too expensive in practice?