Allow Default Value for toNumber("problem", 0)

[titouandk]

It would be nice to be allowed to pass an (optional) default value for the conversion function toNumber().

Currently, toNumber() returns NaN if the passed value is not a number:

toNumber("problem") // => NaN

The following would return 0 instead:

toNumber("problem", 0) // => 0

This would be very useful when using this function to parse config files.

[kapilkumar9395]

@jdalton I would like to take this up if this change is needed or if it's not done already.

[kapilkumar9395]

#5852 - PR

[Trott]

I left this comment on the PR, but I think an options object is probably a better API. _.toNumber(something, somethingElse) is not, to me, a self-evident API. _.toNumber(something, {defaultReturnValue: 0}) or something like that is a bit closer to be self-documenting.

[kapilkumar9395]

Makes sense, let me make this change

[Trott]

It seems like this feature would typically be used to return 0 instead of NaN, but that's already what toFinite() does, and toFinite() has the added bonus of returning usable finite values for Infinity and -Infinity.

[titouandk]

It seems like this feature would typically be used to return 0 instead of NaN, but that's already what toFinite() does, and toFinite() has the added bonus of returning usable finite values for Infinity and -Infinity.

Not necessarily. Any number could be set as a default for a missing/wrong value in a config file. By example a upper limit for a certain amount of money, ...

[Trott]

Not necessarily. Any number could be set as a default for a missing/wrong value in a config file. By example a upper limit for a certain amount of money, ...

That suggests a poorly designed API. A default value is what I would expect when someone provides no value. But this handles situations where invalid information is provided which seems like a footgun/anti-pattern.

As always, I'm not a lodash maintainer, but it does seem like this adds complexity to the API for a usage that is typically better handled in the application itself.

[titouandk]

I agree, treating a wrong value like a missing one is very likely to be a bad idea.
And this is encouraged by the change I suggested...

Maybe was I trying to solve a problem that should not be solved at this level, indeed.