New private function Util._checkNumber instead of checking over isNaN

[johnd0e]

1. isNaN itself is not reliable way to check if value can be converted to number. There a lot of discussions, and I just point to these unit tests: https://run.plnkr.co/plunks/93FPpacuIcXqqKMecLdk/

2. Just making sure that the value is convertible to number is not enough. Instead we should actually convert the value to number as early as possible (otherwise '5'+5 = '55').
   There are some places in code vulnerable to this sort of bugs, and a number of open issues (too lazy to link them right now).

Ref: #7761, #7128.

---

Questions:

• Should we have common method instead of copy-paste (LatLng: stricter arguments validation #7765, Point: arguments validation #7767, this, and potentially a lot of other cases)?
• Better name (validateNumber)?
• Should it be exposed as public method?
• Should it be applied widely (e.g. in all constructors taking number options)?
  This PR contains only 1 fix, as an example.

[IvanSanchez]

LGTM

[IvanSanchez]

Should we have common method instead of copy-paste (LatLng: stricter arguments validation #7765, Point: arguments validation #7767, this, and potentially a lot of other cases)?

IMO, yes. But if it's going to be a common method/function, I'd rather name it without the leading underscore, and put some docstrings.

[johnd0e]

Suggested change

	// keep it private intentionally, because such function implementation
	// heavily depends on it's particular application and unable to suit all the cases
	export function _checkNumber(a) {
	// @function checkNumber(data: Number|String): Number
	// Makes sure that passed `data` is finite number, and returns it.
	// If string is passed - converts it to number trying to avoid coercion pitfalls.
	// Throws error in case of any failure.
	export function checkNumber(a) {

@IvanSanchez
But I'm not sure, because fixing it in public API

• .. makes impossible future internal changes. E.g. what if later we'll decide to throw on strings like '1e9'
• .. opens the door to misusing (remember using Browser.touch)

[Falke-Design]

@IvanSanchez what do you think about that points? I personally would like to have a public function so it can be easy used in plugins. Not everyone should reinvent the wheel.

[johnd0e]

@mourner ?

[Falke-Design]

@mourner what do you think is better? A public or private function for checking if the input is a number.

[Falke-Design]

The open questions is should we make the checkNumber function public or private? I'm for public.

The concerns against public was:

.. makes impossible future internal changes. E.g. what if later we'll decide to throw on strings like '1e9'
.. opens the door to misusing (remember using Browser.touch)

@mourner @IvanSanchez how shall we proceed? It would be good if we decide that. Around 5 PRs and 8 issues are waiting on that decision.

[jonkoops]

I'd argue to make it private, if it creates added value for plugins devs we can always make it public in the future. Let it prove itself first.

[Falke-Design]

@mourner what do you think?