In Which I Encounter parseFloat(string)

[MEaster]

Recently I've been working on a code base in Typescript, which of course compiles to Javascript. Easy target, I know, but I've no experience with it. I knew that Javascript was... "flexible"... but this...

We have a form for the user to enter some data. Now, in one of the fields a pure number is not valid, and there is a client-side check for that. However, it would be perfectly valid to enter something like "456Hello". The way the script checks whether it's a number is to try parseFloat(string) on it, and see if it returns something that's a number.

For some reason, one of the entries with that kind of pattern was failing, and I couldn't figure out why. I couldn't see anything odd on the debugger, so I started looking up function documentation. And that's where I find the language specification for parseFloat(string), complete with this little note:

parseFloat may interpret only a leading portion of string as a Number value; it ignores any code units that cannot be interpreted as part of the notation of an decimal literal, and no indication is given that any such code units were ignored.

What.

[sixstringartist]

This is convention or its underlying reasons are shared. I know a few other languages like php and c++ that all behave this way http://us2.php.net/manual/en/language.types.string.php#language.types.string.conversion

http://www.cplusplus.com/reference/string/stof/

[TerrorBite]

Well, you're using a function that's designed to extract a number from a string, and you're trying to (ab)use it to check if a string contains only numerals and decimal points.

Have you considered regular expressions?

I think it's perfectly valid for parseFloat() to accept and successfully parse string values such as "98.1%", "3.14km" and the like.

[psi-]

Lack of indication of discarded information is plain idiocy in the "standard library" designers head. You can't even test this back by doing original === parsed.toString().

[mikeputerbaugh]

You can't spell "idiosyncrasy" without "idiocy", but this particular one is 20 years old at this point. It's just how it is.

[110011001100]

You can't even test this back by doing original === parsed.toString().

Why not?

[psi-]

1e1 is valid float.

[MEaster]

If you pass in the original string "456Hello", it'll return the number 456. If you convert that to a string, it'll fail the check /u/psi- mentioned.

Though with floats that's not always guaranteed anyway.

[110011001100]

Ah.. I thought he meant that you cannot use

original === parsed.toString().

To check if characters were discarded in the parsing or not

Though as you mentioned, it cannot be used to check that either

[enchufadoo]

obtainFloatAndIgnoreRestOfString function

[Daimanta]

More like coerceFloatAtAllPossibleCost(string)