I'll look at this next week, Viktor.

@MikeMcl ping

Sorry, Viktor. Something came up. Thanks for the reminder.

@MikeMcl It's fine :) Thanks for coming back!

Looks good, but I'm not sure.

In expected usage, it would mean that the regex test is executed twice, with the second test completely redundant:

if (Big.isNumeric(value)) {
  x = new Big(value);
}

Was thinking how to avoid throwing an error altogether,

In bignumber.js, I return a BigNumber with the value NaN if the argument is invalid:

x = new BigNumber(value);
if (!x.isNaN()) {
...

but here there is no Big NaN and I would prefer not to include it as it that would mean having to add code that checks for it everywhere.

One option is to remove the test from the Big constructor, and only include it in the Big.isNumeric method:

x = new Big(2);    // value not checked, and there is no need to check it
value = getValueFromSomewhere();
if (Big.isNumeric(value)) {    // value checked explicitly
  y = new Big(value);
} else { ...

This puts the user in control of when a value gets tested, so unnnecessary checks can be avoided and hence the library becomes slightly more efficient.

The advantage of your implementation though is that existing users could just continue to use the library as normal.

Anyway, I prefer Big.test rather than Big.isNumeric.

Any thoughts?

it would mean that the regex test is executed twice

It bothers me as well. I'd like to avoid it!

In bignumber.js...

Our codebase is using Big.js so moving to another lib is practically not an option :( Besides, I appreciate the fact that this lib is so minimal!

One option is to remove the test from the Big constructor

Yeah, it is an option. But it would introduce quite the breaking change, wouldn't? Will it require to introduce the default value?

This puts the user in control of when a value gets tested, so unnecessary checks can be avoided and hence the library becomes slightly more efficient

You know what, maybe we can add second constructor that will initiate Big instance without test?

const n = new Big.Unsafe('Definitely not a numeric!') // what should happen it this case? 0?

Unsafe constructor will simply mean that it leaves the check for the input to you, developer.

Doing that we have backwards compatibility and not doing redundant second check.

, I prefer Big.test rather than Big.isNumeric

I thought about test as well, but my brain is so used to the fact that only regular expressions have test method on it that I thought it will look weird if Big constructor will suddenly behave like one.

@MikeMcl ping (exactly 11 days just like previous time)

I have decided not to accept this.

This is a minimalist library and the high bar to API additions has not quite been met.

I am not convinced enough by the argument that a try & catch block is too expensive or too complex.

Thanks for your efforts.