Operation result being copy/noncopy is inconsistent for some operations

[razenpok]

I haven't checked other operations, but in some cases add can return the same instance that was passed as left-hand side Decimal.
https://github.com/Patashu/break_infinity.js/blob/master/src/break_infinity.ts#L869

We need to decide if we want Decimal to be

• Faster, with less allocations
• Slower, but without pitfalls

I believe that returning the same instance can lead to some quirky bugs caused by innate mutability of Decimal, but it's your call.
Keep in mind that "faster" and "slower" doesn't really mean object allocation itself (which a really lightweight operation), but instead the fact that it will add to garbage and GC will be invoked sooner.

[Patashu]

As you say the less allocations, the better. We're going for speed here (as much speed as we can get in JS anyway...)

Directly mutating break_infinity.js is allowed, but it shouldn't be a common operation to do say c = Decimal.add(a, b); c.e += 1; or whatever, that would actually be affected by this. I've never heard of anyone being surprised by the behaviour you list.

The main reason to not go full allocationless and mutate arguments is that THAT would be too surprising (if you add or mul what you thought was a constant and break_infinity.js mutates it, that requires you to keep reallocating or cloning your constant, defeating the purpose).