> I look forward to comments telling me how wrong I am.
Okay, I'll try to explain.
The job of a parser is to perform the opposite of stringification as precisely as possible. That string source is not always a human typing on a keyboard.
If your stringifier doesn't output scientific notation, then you reject scientific notation because it's invalid data, plain and simple. It's completely irrelevant that to a human it still looks like it could be some number. It's like picking up the wrong baby at the hospital. It might be lovely and all, but it wasn't what you were supposed to get, and that matters. It's a sign that someone screwed up, potentially badly, and your job is to hunt down where the bug was and how to address it, not just roll with whatever came your way and win some competition on how long you can ignore problems.
If you want to parse natural language then sure, it makes sense. That's what flags and different functions are good for. It doesn't mean that has to be the default. As far as programming languages go, the default assumption is that your Parse() is parsing whatever your ToString() produced on the same type.
"The job of a parser is to perform the opposite of stringification as precisely as possible."
Is it though? String-to-float parsers are quite flexible in the range of inputs they allow. "1000", "1E3", "10E2", "0.1E4", "1000.0", "00000001000.00000000000000" all return the same float value. https://dotnetfiddle.net/K08vk5
(See also sibling comment by "someone".)
If your question is "Is this string the canonical representation of some number?" then a parser function on its own is the wrong tool.
Yeah but floats can typically be formatted with E notation, i.e. it makes sense to parse floats with E notation. I’m not aware of any integer formatting functions that will emit integer strings in E notation. The leading zeros and unary sign mentioned by a sibling comment are typically available options for integer formatting, i.e. make sense to parse according to GPs reasoning. I assume the reason float parsing is more forgiving is because of how often floats are written in E notation, also float parsers typically have to handle things like NaN and inf.
By that logic, I think most toString/fromString pairs are broken. Many “string to int” functions accept some strings that their counterpart “int to string” never produces, for example “-0”, “0000”, and “01”.
(Chances are ‘fromString’ accepts strings with very long prefixes of zeroes)
Having said that, I do think accepting “1E9” may go too far. If you accept that, why would you disallow “12E3”, “1.23E4”, “12300E-2”?
If you’re going to widen what the function accepts, I would add support for hexadecimal (“0x34”) and binary (“0b1001”) before adding this.
Yes, the prefix of zeros (and a plus sign) are exactly what I'd expect to enable via flags, not as a default. Especially because zero prefix isn't even always insignificant - it denotes octal in some contexts.
I think you're mixing up parsers and deserialisers here.