Suggestion: Drop the signbit

[dou4cc]

Before BigInt, the following usual equivalent implementations can all convert a to a number unless throw:

Number(a);
+a;
- -a;
1 * a;

Now:

a = 0n;
Number(a); // 0
+a; // TypeError
- -a; // 0n ← WTF??
1 * a; // TypeError

Suggestion: Drop the signbit of BigInt

[bakkot]

This doesn't affect existing code unless someone adds new code to the page, so no, it wouldn't break the web. There may be existing code whose assumptions are no longer valid in the presence of new code, but that's true for many features.

I don't think avoiding this hazard is worth not having negative integers.

[littledan]

Suggestion: Drop the signbit of BigInt

What would this mean?

[dou4cc]

This doesn't affect existing code unless someone adds new code to the page, so no, it wouldn't break the web.

Ok. So why forbid +0n? It is inconsistent.

[dou4cc]

Suggestion: Drop the signbit of BigInt

What would this mean?

It means that we can make BigInt unsigned since as a basis feature for scientific calculations, natural number is enough.

[bakkot]

Ok. So why forbid +0n? It is inconsistent.

See #25.

[dou4cc]

Ok. So why forbid +0n? It is inconsistent.

See #25.

I mean otherwise it should be:

+0n === 0n

[dou4cc]

Without signbit, BigInt would become compatible with >>>, which is a win win.

[dou4cc]

Quite strange:

String(0); // "0"

String(0n); // "0"

-{[Symbol.toPrimitive]: hint => {
	throw new EvalError(hint);
}}; // EvalError: number

-{[Symbol.toPrimitive]: () => "0"}; // -0

-{[Symbol.toPrimitive]: () => 0n}; // 0n

typeof 0n; // "bigint"

+{[Symbol.toPrimitive]: () => 0n}; // TypeError: Cannot convert a BigInt value to a number

[littledan]

These were all explicit design decisions, and I don't see any reason in this thread to change things. Feel free to reopen with more motivation.

[dou4cc]

Closed because the proposal seems not going to separate number and bigInt completely.