Runtime: Problems with thousands separators when parsing strings to numbers

[varocarbas]

Since some months ago, I have been aware about the problems that the parsing methods (at least, Parse and TryParse) of various numerical types (at least, Decimal and Double) have when dealing with thousands separators (at least in .NET 4.5; in both C# and VB.NET). The following C# sample code illustrates the point well:

C# string stringVal = "1,1.1"; decimal decVal = 0m; if (decimal.TryParse(stringVal, NumberStyles.Any, CultureInfo.InvariantCulture, out decVal)) { //This part will be reached, because decimal.TryParse thinks that 1,1.1 is a valid number }

Such misbehaviour can be replicated under many different conditions. The basic idea is that the parsing approaches don't understand what the thousands separators really imply (i.e., groups of 3 numbers in the aforementioned example).

Today, I focused my analysis of the code on the Decimal type and found ParseNumber (mscorlib\src\System\Number.cs). The way in which this method treats the thousands separators (in all their forms) explains perfectly the observed behaviour: it focus the analysis on valid/invalid characters and doesn't bring into account the size of the group at any point.

My proposal consists in forcing the corresponding methods to trigger an error when the thousands separators aren't in the right positions. My intention is firstly focusing on the Decimal type (although the aforementioned method is most likely used by other types too). After having ready a good enough correction for Decimal, I will analyse the remaining types in detail and perform additional changes if required.

The correction will consist in analysing the input string; in case of including thousands separators, their locations would be checked. If this analysis fails, no conversion to number would be performed. In principle, I am planning to take advantage from the current implementation (more specifically, a loop analysing all the characters) and rely on “low level” approaches; although I have still to think carefully about the exact algorithm.

[varocarbas]

I am new here and I am not sure how all this works. So, I will better wait for a reply before starting anything.

[mikedn]

Such misbehaviour can be replicated under many different conditions. The basic idea is that the parsing approaches don't understand what the thousands separators really imply (i.e., groups of 3 numbers in the aforementioned example).

Why exactly is this a bug? There doesn't appear to be anything in the documentation of decimal.TryParse that requires group sizing to be enforced. Also, group sizing doesn't affect the numeric result in any way - 12,34,56.78 is exactly the same value as 123,456.78. Changing this behavior now seems like a gratuitous breaking change.

[varocarbas]

@mikedn When I use Decimal.TryParse (or an equivalent method of other numerical type), I expect to get true when the given string represents a valid number (on account of the given type and culture) and false otherwise. "1,1.2" or "1,,,,,5" (yes, it also accepts this last one) or similar are not valid numbers, but the current implementation might recognise them as such (i.e., bug). What is the difference between these examples and "111#12"? This is not a valid number either, but is it less valid than the aforementioned one? Do you prefer to always extract all the relevant information (i.e., numbers) and only output false when strictly required (no numbers at all)? Then why is “111#12” not accepted too?

The most ironic part is that I usually ignore thousands separators (not too typical in Spain, my country; neither in the kind of fields where I am more experienced). I knew about this "issue" some months ago while answering a SO question of someone being very interested in triggering an error for these cases. After this question (which BTW was solved by relying on manually pre-checking the format), I have seen at least 2 additional ones on the same lines. Thus, I am quite sure that this behaviour is not what some people expect and that they plainly don't trust the in-built parsing methods (i.e., doing a format check before using a parsing method?!).

Regarding what you say of "doesn't appear to be anything in the documentation...", note that the method which deals with these actions (the one I am mentioning in my first post) precisely includes a comment explaining the supported situations, where properly accounting for the locations of thousands separators is not being mentioned (as said, the method doesn't even deal with the required information). In any case, I don't think that this issue is relevant at all; other than for supporting the differentiation between bug in the code (i.e., a mistake in the actual implementation) and bug in the underlying logic (i.e., pursued goal not right enough).

Lastly, I want to highlight that the required correction would have a really low impact. I have already analysed this specific bit of code and can include this functionality by just accounting for a couple of additional variables in a loop. On the other hand, one of the outputs of carefully analysing this method might even be a slight improvement of its performance.

[mikedn]

What is the difference between these examples and "111#12"?

It seems obvious to me, # is invalid character in this context while , is not.

I knew about this "issue" some months ago while answering a SO question of someone being very interested in triggering an error for these cases.

It may be useful to include a link to that question or at least an excerpt from it if you want to convince people that a breaking change is necessary.

precisely includes a comment explaining the supported situations, where properly accounting for the locations of thousands separators is not being mentioned (as said, the method doesn't even deal with the required information).

I don't see any such comment but anyway, what does that have to do with what the documentation says?

Lastly, I want to highlight that the required correction would have a really low impact.

How do you know that? There may be code out there which parses text which contains such numbers and all of the sudden that code will stop working.

[varocarbas]

@mikedn So, you think that a parsing method which accepts "1,,,,,,,,,,,,,,,,," as valid number is fine because "," are the thousands separators in the given culture? Then why not accepting "1..........." too? What makes the thousands separators so special?

Regarding linking to the SO questions, I can easily locate one (because I answered it); but not so sure regarding the others questions. Although if this is a basic requirement to do what I consider required, I might do some effort.

Regarding why I think that it would have no impact? Exactly for the same reason why I consider that I can fix it: because I have quite a long experience on (efficient) algorithm building and know what I am talking about :)

BTW, do you know what are the expected next steps? Should I just wait here until someone in the .NET considers that my suggestion is relevant?

[mikedn]

So, you think that a parsing method which accepts "1,,,,,,,,,,,,,,,,," as valid number is fine because "," are the thousands separators in the given culture?

What I'm trying to say first and foremost is that this is a breaking change and as such it needs to be treated carefully. It's more important how this change affects existing code than the fact that that it can be fixed, or if the fix is efficient or if there's who knows what comment in the source code.

[Joe4evr]

So, you think that a parsing method which accepts "1,,,,,,,,,,,,,,,,," as valid number is fine because "," are the thousands separators in the given culture? Then why not accepting "1..........." too? What makes the thousands separators so special?

Nothing, really. Numeric separators aren't by the thousands everywhere on Earth. And they aren't commas everywhere on Earth, either. Numbers are really confusing once you bring culture into the mix.

[varocarbas]

@Joe4evr It was a rhetorical question. The current implementation of Decimal.Parse (or similar) accepts "1,,,,,,,,,," as valid, but triggers an error with "1............". Does it make sense? No. That's why I am suggesting to change it (what @mikedn thinks that is not a good idea).

PS: if you think that numbers are confusing why are you commenting in a thread aiming to change the source code dealing with these issues?! Note that the culture is being brought into account always when parsing decimal (when using an overload not taking this argument, the code would assume a default one).
PS2: don't want to offend anyone, but I was expecting a bit more of "action" (i.e., actually implementing changes or discussing with actually knowledgeable people in the given implementation). All what I see here is general talking.

[mikedn]

but triggers an error with "1............". Does it make sense? No.

The decimal point has a very specific meaning and its presence and position affects the result. IMO the fact that 1..... triggers an error makes sense.

[mikedn]

if you think that numbers are confusing why are you commenting in a thread aiming to change the source code dealing with these issues

The real problem here is that you think that this is about changing a bit of code somewhere. It is not, it's about changing the behavior of a commonly used framework API.

[varocarbas]

@mikedn I am seriously not interested in convincing anyone or tolerating not-completely-straightforward/honest attitudes. I have explained my point clearly, would love performing this modifications (and quite a few other ones) but if I cannot I would accept it (haven't had anything until yesterday).

The situation is very clear: you have "1,,,,,,,,,,,,," being accepted as a valid number. Do you want that? Excellent; but let's better not waste everyon's time by trying to prove that this should actually be the case (you don't have any way to convince me of such a thing).

I have made my proposals and spent a relevant amount of time explaining different issues. If you (the decision-makers) consider that I might go ahead (or even that I should provide further informtion), please let me know.

[shahid-pk]

@varocarbas lets say i am user of this TryParse i am depending on 1,,,,,,,,,,,,,,, to be valid why ? because this behavior is their for almost 10 years , i don't know how many apps i have developed depend on this. If you change this you will break all my apps. Do you have a solution that fix this and does not break all my ten or so app that is using the old behaviour ?

[varocarbas]

@shahid-pk what you are saying doesn't make any (practical) sense. Please, take a look at my following comment.

[varocarbas]

Thanks for your contributions, but seriously this is not what I want.

I have started some threads which I consider completely clear. If I am wrong and this community doesn't think like me, I would not implement anything (and, most likely, wouldn't contribute further).

I like objectivity-driven communities where all their members have similar knowledge and expectations and where subjectivity is not favoured. The open .NET seems a perfect excuse for objective-correctness-focused discussions where everyone would win (Microsoft by getting a beyond-excellent product and the contributors by working on so worthy resources; seriously, after taking a quick look at CoreFX & CoreCLR I am speechless); this situation is certainly very appealing to me. Participating in random chats with random people (no offense) about random issues is not what I want.

Please, if you have solid enough expertise related to what is being discussed here (e.g., efficient algorithm building, deep .NET knowledge mainly regarding this specific implementation, you are an local decision-maker, etc.) and you want to share anything with me (question, suggestion, request, etc.) from a completely technical and objective perspective, please feel free to contact me. Otherwise, I would not answer you. As said, no disrespect intended, just trying to avoid everyone wasting their time.

[mikedn]

I am seriously not interested in convincing anyone or tolerating not-completely-straightforward/honest attitudes.

I'll pretend that I didn't see this baseless accusation.

I have explained my point clearly, would love performing this modifications (and quite a few other ones)

That's all fine and appreciated but again, this isn't about changing the code.

If you (the decision-makers) consider that I might go ahead

Decision makers (Microsoft people) have yet to comment on this matter. Neither me nor anyone else who commented in this thread up to now do not work for Microsoft. But the decision makes have clearly stated (and documented) in the past that breaking changes need to be discussed. That's exactly what we are doing now but it appears you're not willing to have a discussion.

if you have solid enough expertise related to what is being discussed here (e.g., efficient algorithm building, deep .NET knowledge mainly regarding this specific implementation, you are an local decision-maker, etc.)

Again, we're not discussing any implementation details, we're discussing the behavior of the API. I don't know how to make this more clear, you're approaching this from the wrong angle.

[varocarbas]

@mikedn I am answering mostly to highlight that you misunderstood comment ("see this baseless accusation"). My bothering-you comment wasn't exactly addressed to you and was meant in a quite wide sense on the lines of "subjective views when dealing with objective facts". I have been answering comments from quite a few people for a while; what was tiring, because I don't like it (wasn't expecting it here and don't even think that things here should be that way).

I am not trying to criticise anyone's approach, just clearly stating what I am willing to do. I am more than happy to explain what is required from a strictly technical perspective; to convert my "I think that" into verifiable facts. Also in case of being required, I am very happy in following a more or less complex process (even involving some random chatting) but only in case of aiming a clearly-defined goal (not the case so far).

What about if I exclusively participate in conversations dealing with the implementation aspects? You can discuss as much as you wish, come to any conclusion and letting me know only in case of thinking that my approach is worthy. Would this be acceptable?

[mikedn]

I am more than happy to explain what is required from a strictly technical perspective; to convert my "I think that" into verifiable facts

What is required? I'm more interested to know why is this change required, a real world use case where the current behavior poses a problem.

[varocarbas]

http://stackoverflow.com/questions/32676992/validate-currency-textbox/32677430

[varocarbas]

But you can find quite a few more examples after a quick research:
http://stackoverflow.com/questions/831727/c-sharp-decimal-parse-issue-with-commas
http://stackoverflow.com/questions/2094254/number-parsing-weirdness
http://www.vbforums.com/showthread.php?643055-RESOLVED-Double-TryParse-returns-true-for-quot-19-6-quot

[mikedn]

None of those posts seem to answer the "why?". People simply say "I want X" but nobody explains why.

I have 2 online banking accounts and I was curious to see what happens if you enter something like 12,34,3. One simply ignores all the commas and the other doesn't allow you to type any commas (which IMO is the best thing to do). If banks have no problems with digit grouping then why is this a significant problem for a WinForms app?

If you try to copy/paste 12,3,4 in the Windows calculator you get 1234. Excel doesn't treat 12,3,4 as number but then Excel is a rather special case because it tries to distinguish text from numbers.

If this fix/change was for .NET 1.0 Beta then it would have been perfectly fine but it's .NET 4.6.x we're talking about and introducing a breaking change simply because someone wants it but offers no justification won't be easy.

[varocarbas]

@mikedn (This is precisely the kind of conversation which I don't want to have, because of representing a pure waste of time. A more-sensible-than-me person would plainly ignore such a pointless argument, but I am too damn respectful and don't like ignoring people. You clearly come from a completely different background and I don't have any interest in convincing you of anything, just in showing what I consider relevant to people thinking like me. Not sure about the reason why you are so interested in continuing a conversation with a person seeing things from a completely different perspective than you do. This one will be my last reply to comments on these lines)

All what you are saying doesn't make any sense! You are talking about applications. You are not facing the problem as a programmer, but as a user! If you click on a button, you don't know what this program is internally doing! We are precisely discussing about these internals!

You seriously think that if Decimal.Parse fails in certain situation, all the applications relying on it would fail too?! Only the applications built by incompetent programmers would fail. Competent programmers create applications which will always work independently upon virtually anything else (e.g., the errors of the given programming language, how clueless the given user might be, etc.)!

The applications created with .NET 2.0 (and before .NET existed) didn't include lots of fancy features which the last version includes, but basic functionalities like inputting "12,2,3" and not getting any error were still working anyway. With loops, conditions and a couple of things more you can create almost anything; although this is not the goal of the modern programming languages (i.e., basic functionalities), but being as programmer-friendly as possible (e.g., to maximise productivity), to not mention the internal consistency of the given environment (perhaps irrelevant to you, but not to everyone).

Have you read all the questions in my previous comment? What do you think that these people were doing after realising that the decimal (or double or float) parsing method wasn't working as expected?! Letting it like this? Creating a warning saying "Sorry, the functionality which you have requested is still not accounted by .NET"?! If you have to multiply 5 times 5 and the multiplication sign of your calculator doesn't work, you can do 5+5+5+5+5; would that mean that the multiplication sign doesn't need to be fixed? No. You need the multiplication sign to do things easily and quickly. And even worse: if you are commercialising calculators and one of your clients comes to you complaining about the multiplication sign not working, would you say him "use the addition sign"? What would that client think of your professionalism and the reliability of your products?

Please, stop converting what seemed a true dream (being able to perform relevant modifications in CoreCLR & CoreFX) in meaningless conversations which I don't want to have.

[mikedn]

Please, stop converting what seemed a true dream

I'm not converting any dream, I'm just trying to wake you up.

[varocarbas]

@mikedn Wake me up? From what? Do you think that I don’t have experience in dealing with cluelessness? That I haven’t seen lots of problems provoked for no reason? That a win-win situation can easily be converted into a lose-lose one? I am perfectly aware about this sad reality (much more than what the attitude I show might indicate; in fact, I don't trust in people’s proper understanding and practicality since some time ago).

FYI, the dream already came true (I have full access to an impressive code; thanks again Microsoft, you made me really happy :)). It would be quite nice to allow others to also benefit from all what I will be doing with that code; but to be honest, I don't have many hopes on this front (as said, I have long experience dealing with pure nonsense).

[aevitas]

I am new here and I am not sure how all this works.

@varocarbas Fairly certain the way you're approaching this right now won't get you very far. Accusing people at random while praising your own achievements/skills, instead of providing concrete, real-world cases of why a change that would break backward-compatibility on an extremely widely used API that has been in the framework with its current behaviour for over a decade would be required.

There are countless applications running business critical logic that rely on this API for them to work. If that API were to suddenly change when the target platform for those applications changes, without any notice, then that could be an absolute disaster. The fact that you don't seem to grasp that is simply beyond me.

Barging in here shouting that you're not interested in discussion and your proposed change is the be-all-end-all solution to a huge (but non-existent) problem, is not in the spirit of this community. You're not Torvalds, and this isn't the Linux repository. Get a grip.

[janvorli]

@varocarbas When you work on something like .NET that has millions of developers targetting it, you cannot afford to fix somethings in a way that would break substantial amount of existing applications. Even though the fact that they relied on the broken behavior can mean that they were not great programmers. Because if you do that, you hit the users of those applications and they will blame you, not the application developer. From their point of view, they had an app that was working fine, but when they upgraded to the latest .NET framework runtime, the app stopped working.
Of course bugs should get fixed in general, but one need to be extremely careful about the way to fix them so that the fix doesn't break others.

[shahid-pk]

@varocarbas no one is questioning your skills or ability here , all that we are questioning is your idea and giving our views on your idea. Even the developers that are professionally developing .net gets questions like these.
You have to understand that this is not targeted only to you or only to your idea, when you create an issue/or mail on any open source project which brings a new idea, others developers give their views on that idea , this is how open source works. This is certainly not to discourage you but to encourage you to reason about your change taking into account every concern that is raised.
Coming to this issue if you look it from front yes this a behavioral bug which in a perfect world should be fixed but we don't live in a perfect world , we live in a world in which ms has shipped this behavior for ten years or so and people like you and me are working around this bug, so a change in the behavior will break those workarounds , and no one can be certain that this change won't break many many applications. Neither can we say to users of .net that your application was working on .net 4.6.1 but now your application is broken on .net 4.6.2 because you are a bad programmer and you used our buggy TryParse which we just now fixed.
Further more we can only talk about the technicalities of the code that you would write if all the stalk holders agree to bring this breaking change. Which is the easiest part because as i said earlier no one is questioning your capability or ability.

[varocarbas]

Please, I don't want to continue with all this. My first comment should be descriptive enough, but here comes a last summary:

• Clear bug (e.g., accepting "1,,,,,,,," as a valid number; but triggering an error with "1.......").
• I found already the exact place where it is located; and the eventual correction would have a very low impact (i.e., just accounting for a couple of variables more in a loop); I might even analyse the situation further to see if I could get an additional improvement in performance (what after a quick look seems possible -> but have to analyse it more carefully).
• It is very unlikely (to not say virtually impossible) that any (serious-enough) code has ever relied on a so unexpected behaviour (tolerating thousands separators in any position, but not anything else?). On the other hand, there are quite a few references where this behaviour is considered quite illogical, as shown in the links above. Note that most likely this problem has always been present (since .NET was created), but people keep complaining (although I have seen some "thousands parsing is very unreliable, better check the format manually" attitudes, which I am not sure that are too positive).

Regarding my personality and expectations:

• I am new here, but with no interest in adapting myself to what I don't consider appealing enough. That is: I want to reduce the social/subjective essence to its minimum expression and focus most of my interactions on technically-relevant issues. If this is not possible (a perfectly logical scenario), I would plainly accept that direct contributions like this one are not for me (and might think about alternatives).
• I want to focus any conversation on strictly technical aspects, which might be objectively proved (e.g. by testing these cases under those conditions, this version took x secs. and this other version y secs.).
• I don't want to talk about abstract issues, expectations, assumptions, etc.
• I want to exclusively deal with programmers who are experienced enough in .NET (and, ideally, in CoreCLR) and by always focusing on issues which are directly related to programming.
• I understand that this is a big community with lots of different opinions and that other types of discussions will be occurring. I would like to not participate in any of them; just discuss about anything you want and come to your conclusions. I will accept the resulting decisions.

I am not trying to be disrespectful, just minimising useless wastes of time by highlighting some useful facts. Logically, I will accept all the consequences of my attitude (e.g., my two proposals being rejected); and I expect anyone else to do exactly the same thing (i.e., if you want to discuss about issues which I don't consider relevant, I would plainly not answer you).

I understand that all this might sounds a bit weird, but at least it is crystal clear :)

[aevitas]

@varocarbas Your passion for technical details is admirable, but unfortunately, software development - and especially on the scale of .NET - revolves around expectations, promises, and assumptions. Merely by saying "_It is very unlikely (to not say virtually impossible) that any (serious-enough) code has ever relied on a so unexpected behaviour_", you are already creating assumptions of your own.

Not all people, and indeed not all programmers, are created equal, and although most of us prefer the vacuum of technical implementation details, when it comes to proposing changes to a long-established code base, discussion such as in this issue is a required part of the process. Your proposal may indeed have merit, and there is no one turning it down saying that is doesn't straight off the bat - they are merely proposing opposing views. Whether that is a process you would like to participate in or not, is entirely your choice.

[PapaCharlie]

@varocarbas Unfortunately, this has nothing to do with your culture or locality, but rather with the standards of the language, the library and its culture. You say:

Clear bug (e.g., accepting "1,,,,,,,," as a valid number; but triggering an error with "1.......").

But it is not a clear bug, in fact it's not a bug at all. In the American standard, the thousands operator is indeed optional, and while writing numbers like this: "12,34,56.3" is frowned upon, it is not incorrect. On the other hand, there can be at most one decimal point, otherwise the string of digits cannot be interpreted as a valid number. The reason I am talking about the American standard here is because the underlying logic of this library, and the .NET framework, is built upon this standard. If the .NET framework were forced to also accommodate other standards, then I might as well request that the "for" keyword be changed to "para" for all the same reasons you want to change the behavior of this function. You want this function to behave in a non-standard way, which is by definition a code-breaking change. As a matter of fact, the behavior you are proposing would be considered a bug, not the other way around.

[RobThree]

I would like to quote some comments from Reddit:

For example if you accepted a formatted value 1,234,567 with the user deleting the last two characters it could become an input of 1,234,5 and currently the method would accept this value.
If the user deleted everything but the first digit it would be 1,, and still be valid. The number of comma's is entirely arbitrary at this point. - (Losobie)

Even worse: suppose I entered 1,000,000,000 and realise I've entered one too many zeroes I have to now not only delete only the last zero, I also need to re-arrange all the thousands separators and, effectively, re-enter the entire number.

The correct answer to why he's wrong is that thousands separators in numbers are semantically insignificant whitespace and numbers can only have one radix, since the radix signifies the ones place. Thus, a radix is significant, and a thousands separator is not. We _could_ say that the first radix in a string is the canonical one for that string, but that would be a decision of the specification maker. What would make much _less_ sense is treating semantically insignificant whitespace as semantically significant. (Godd2)

Good point IMHO.

Then there's the "detail" that a thousands-separator is not always used to group digits in threes (so I'm not quite sure how 'simple' a 'fix' would be (if you're gonna fix it, do it right, right? :stuck_out_tongue: ) , might be harder than you think):

The Indian numbering system is somewhat more complex: it groups the rightmost three digits in a similar manner to European languages but then groups every two digits thereafter: 1.5 million would accordingly be written 15,00,000 and […]. (Wikipedia)

The International Bureau of Weights and Measures states that "when there are only four digits before or after the decimal marker, it is customary not to use a space to isolate a single digit" (Wikipedia)

The above quotes are, to me, reason enough to treat thousands separators as 'whitespace' or 'noise' if you will; they're only for (human) readability and change nothing to the meaning of the number. So why bother with them at all when parsing a number?

Yes, 1,,,,,, doesn't make sense and yes maybe a, for example, ParseStrict() method should make it's way into .Net but changing behavior _on existing methods_ people (knowingly or _un_knowingly) rely on is a dangerous thing and should not be taken lightly.

And I'd like to leave with a quote from myself:

Such changes require […] shims, maybe even a (new overload with a) extra argument to the […] methods that allow you to specify the desired behavior or maybe even a whole new method needs to be created […].

Nobody is saying that the current behavior is absolutely perfect and nobody is saying there's nothing wrong with current behavior. They are, however, saying that such changes can't be made on a whim or go overnight. It needs careful consideration and deliberation.

[jakesays-old]

@varocarbas You are _completely_ missing the valid point @mikedn is trying to make. _HOW_ the code should work in your opinion is irrelevant. What is relevant is the fact that the current behavior is what people _expect_, and has been what they expect for 15 years now. You cannot make a breaking change like this, not even to make the code 'correct.' If you do you run the risk of potentially breaking _thousands_ of applications.

I really do not understand why you are having such difficulty with this concept.

[Davio]

There is a difference between being parseable (which is always a best-effort kind of thing, trying not to break on things it can deal with) and being strictly valid in a certain context (in this case in a certain default culture), they're not the same; valid is always going to be a subset of parseable. A number like " 1.2 " (note the whitespace) isn't strictly valid, but I'm glad it can be parsed.

[Havvy]

It is a technical issue that making a breaking change breaks programs that already exist. If you don't care about backwards compatibility, you can ignore it, but the CLR cares about backwards compatibility, so it is stuck with the decision made 10 years ago. Because of this, even though it is feasible to write the code to change it, it is not possible to publish it in the mainline CLR.

[mgravell]

To me, the fundamental problem here is that you are asserting a particular definition of "correct", but that definition is highly questionable. You say string stringVal = "1,1.1"; is not a valid decimal. Well... yes, yes it is. It might not be _in the most commonly expressed form for that culture_, but: it is _perfectly_ well-formed, unambiguous, etc. There is no reason _not_ to accept this (contrast "1.1.1", since . in the stated culture has a very different impact), unless we're using TryParseExact. Now; decimal _doesn't have_ a TryParseExact, but some other types do.

If the conversation were restructured to

Proposal: add TryParseExact to numeric types, enforcing expected formatting rules including group separator positions, etc

then I could _totally get behind that proposal_. But: the API at the moment is perfectly valid - it just isn't what _you_ expect. That's fine; it doesn't have to be.

[varocarbas]

Thanks again for all your contributions. I insist in the fact that there are many comments, most of them focused on certain ideas about which I don't want to discuss (i.e., if you think in this way, I would accept your decision; trying to convince you is not one of my priorities).

Some of the last comments are highlighting issues with a slight technical essence which might need some clarification (well… not ideally); this is the main reason for writing this new comment.

Note that I use expressions like ".", ",", “thousands separators with certain number of digits in between” just to simplify ideas. I really mean: “decimal separator within the given culture”, “group separator within the given culture” and “size of the group in the given culture”. The original version of the parsing method (i.e., the one which I am referring in my first comment) logically accounts for the given culture (not for "." or ","; but for the decimal/group separator in the given culture); that is: the string is already being parsed on account of the expected format. Curiously, this information is not being fully maximised and that why the error I am referring happens: this method does know the size of the group/thousand separator (even if groups are acceptable/not in the given culture), but it doesn't use it at all. Although it does use the given group separator character; that's why the referred faulty reality exists: "1....." being wrong and "1,,,," being right (logically, I mean the English/Invariant culture; the one which this method takes by default in case that the user doesn't expressly input a different one).

I hope that this point is now clear. I hope that you will continue enjoying your discussion. Again thanks to everyone for sharing your thoughts. Again, no disrespect intended (but why do I have to clarify things which should be evident to the kind of people I want to discuss with, that is: knowledge-enough on this specific issue?). And again, make the decision you wish and contact me only for issues strictly related with the actual implementation.

[varocarbas]

@mgravell is talking to me!!! Ah!!! I am kidding, but you are kind of a legend, you know? :)

Sorry to disagree with you, but "1,1.1" is plainly wrong not subjectively wrong. There is no valid reason explaining why "1..1" is wrong and "1,,1" is right.

On the other hand and as explained many times before, I do understand that there are many more issues involved when deciding to perform certain modification. I am not trying to convince anyone about the main priorities here (i.e., keeping backwards compatibility no matter what vs. being somehow adaptable on this front). I am not even saying that am in a position to know what is best (you, for example, have certainly much more experience than me on big developments and on coordinating different expectations). I have proposed a modification which I consider worthy. Doesn't the .NET community think like me? I would accept any decision (but not necessarily agree with it).

[jakesays-old]

@varocarbas "1,1.1" is 'right' because the ',' HAS NO MEANING when it comes to parsing numbers. the ',' is there SOLELY FOR HUMAN READABILITY and offers NO semantic value. However the '.' IS semantically important, so 1....1 is clearly not a valid number. 1,1.1 is semantically valid because 1,1.1 is the NUMERIC equivalent of 11.1. Can you not understand this?

[varocarbas]

@jakesays Please, don't force me to be involved in a conversation which I don't want to be part of. I have been crystal clear on this front in my previous-to-last message (i.e., with "," I mean group separator in the given culture). Try to make some effort to understand properly, rather than arbitrarily criticising every single word (and/or defending something as pointless as "1,,1" being a number and "1..1" not being a number).

[jakesays-old]

@varocarbas Oh I do understand very well what you are after. And you have already involved yourself in the situation you don't want by refusing to consider the _objective_ opinions of those of us who have a grasp of the bigger picture. Our concern is how your suggestions will potentially affect thousands of developers and systems. I am amazed that you cannot grasp this concept. Do you not think it important that these developers and systems be affected? Does that have no value to you?

[mgravell]

There is no valid reason explaining why "1..1" is wrong and "1,,1" is right.

Yes, there is. You are just ignoring what people are saying about it. Group separators are essentially only padding. 12345678 is identical to 12,345,678 is identical to 12,34,56,78 (clarification: in a culture where groups are comma-separated). You probably wouldn't choose the last form (although various group lengths exist in different cultures, including groups of different length depending on position), but it isn't invalid. The decimal separator is completely different; it can only appear once, and if it appears more than once there is no valid way of interpreting the data. Trying to emphasize "1..1" vs "1,,1" actually weakens your argument.

I have proposed a modification which I consider worthy.

And people are pointing out the many ways in which this modification would be undesirable and unhelpful - and that is before you get to the problems of multi-targeting (it would be very bad if decimal.Parse did completely different things on dnxcore50 vs dnx451). And hence also why the "perhaps add a new TryParseExact etc" could be a viable alternative that achieves what _you_ want, without hitting all the bumps in the road.

[varocarbas]

@jakesays I think that you are the one not getting the idea. I haven't doubted even a single second about my limited expertise regarding so big implementations. That's why I said: "discuss for as long as you wish and come to your conclusions". I want to continue focusing my activity on mere implementation aspects (i.e., "you have the go ahead; do that") and not having to worried about all these issues.

When I wrote this proposal, my intention was triggering the process to perform the correction; but being exclusively involved in the correction itself (not in all the required discussions driving to the final decision). As said since a while ago: no disrespect intended; just don't want to participate in certain discussions; because I don't like them, do recognise my limited expertise on certain aspects and do want to continue having my less-bigger-picture ideas.

[jakesays-old]

Ok then you have communicated your position on the implementation aspects of your idea. However you cannot propose such an idea and _not_ involve yourself in the larger picture because of its importance. I would suggest you attempt to learn from the comments of others so that you may be able to fully participate in the process.

[varocarbas]

@mgravell Someone proposed the TryParseExact alternative before and I thought the same than now: it seems much more complicated. But I insist in my limited experience on certain issues. If you think that this would be a better solution, you might be right (although still not too sure why something like parsing "1,," as a valid number should be supported at all).

[Davio]

Still I insist you try to see the difference between "something that can be parsed" (can be turned into a decimal number with no ambiguity) and "something which is strictly valid given a certain culture". You seem to think these are one and the same while they're in fact not.

And who even decides what's strictly valid? Certainly not you, is there an official RFC for number representation or an ISO standard? I can't seem to find one. So all we have to go on are some real world examples and in that case it's very helpful if the parser accepts a wide range of possible values (as long as there's no ambiguity about the number it represents) instead of trying to be limited. 1,,,,,1 is just as straightforward for the parser as 11, there's really no harm in it being able to parse it.

[varocarbas]

@Davio The problem is that accepting "1,,,1" and rejecting "1...1" is ambiguous and arbitrary. And this behaviour responds to the mere fact that the algorithm taking care of string parsing didn't account properly for the more-complex group/thousands separators reality (i.e., what, IMHO, represents a bug); even despite of having all the required information available.

Anyway, thanks for your inputs and please understand that I don't want to get involved in certain discussions. I will accept whatever decision the community (I mean, Microsoft) will make.

[MartinJohns]

The problem is that accepting "1,,,1" and rejecting "1...1" is ambiguous and arbitrary.

It was mentioned multiple times already that this is not ambiguous or arbitrary in any way. The one is a padding character ignored by the parsing algorithm, the other is a separation character which identifies when the floating-point part begins.

[Davio]

No it isn't. 1,,,1 isn't ambiguous, it can only be 11. 1...1 just isn't a number (would it be 1.1? or 1.001? 1.0.0.1, that's not even a number. something else? this is why a number may only have 1 decimal separator)

You seem to have a problem with the group size, especially when it's 0, but the group sizes can be really awkward (for instance in India you can have something like 1,00,00,000), now do you choose group size 2 or 3 here? Both won't work. The option which works best (is able to parse most numbers) is to just disregard the group size and group separator altogether and that's what's currently happening and there's no need to change that. If you can't be convinced, well, I'll stop wasting my time talking to a wall.

[mgravell]

Someone proposed the TryParseExact alternative before and I thought the same than now: it seems much more complicated.

I fail to see how. It is a pre-existing pattern that expresses an intent to follow _strict_ formatting rules, rather than lenient ones (the default). It seems to be exactly what you are after.

Additionally, to highlight the impact: from my perspective (as a library author targeting multiple platforms), anything _other_ than this approach can _basically_ be rephrased as "you can't use Parse or TryParse any more, and need to remove it from any existing libraries". In the real world, you can't fundamentally alter what a method _means_. What you propose is not a bug fix, it is not a feature request (additional support): it is a major breaking "this method now means something completely different". And simply: _that is never going to fly_.

[varocarbas]

@Davio "well, I'll stop wasting my time talking to a wall." -> thanks for giving me a break and allowing me to stop answering what I consider irrelevant concerns from a most-likely unreasonable person (yes, you are the wall in my book).

[doomchild]

Fundamentally altering the use case for any method older than about six months is technical suicide. Changing what a method assumes about its inputs falls directly into this zone.

[varocarbas]

@mgravell These are my first attempts here and I am still getting used to the format (even to know how to deal with the .NET team).

A priori a whole new TryParseExact method seemed much more difficult to sell; although by bearing in mind the no-basic-changes attitude here, I guess that this option might have better chances. Failing and learning, like in any other situation. Thanks for your inputs.

[MartinJohns]

These are my first attempts here and I am still getting used to this format (even to how to deal with the .NET team).

This is a public format. You are not only dealing with the .NET team, but with the whole community instead. This is nothing you can avoid if you want to participate in this format. You can't just ignore what other people say and "focus on the implementation only" - there are lot of concerns that have been brought up and that need to be evaluated. This is a public format and you don't decide on how the conversation goes. And saying this like "_with no interest in adapting myself to what I don't consider appealing enough._" is the absolute worst way to go.

[AyrA]

since @varocarbas seems to misunderstand basic number formats, I recommend reading this first: https://en.wikipedia.org/wiki/Decimal_mark

After this has been done, please direct us to the standard we violate by allowing a number to have consecutive grouping delimiters.

[varocarbas]

@AyrA (This is the last time I try to address a clueless question, to not mention what I think about the aparent good-faith/proper-understanding of the commentator)

For all you people extremely keen on abstractly discussing about random misinterpretations of my words and with presumably a quite limited knowledge about how parsing of string to decimal numbers is actually happening in .NET (and well... in most of others modern languages), here you have some basics:

Invariant Culture/en-US/one used by default in the parsing method mentioned in my first comment
"1,1.1" -> wrong (wrongly parsed as right).
"1,000.0" -> right (rightly parsed as right).
On the group/thousands separators front, this specific culture is completely defined with the following 2 variables: "," as group separator and 3 as the size of the group. That is: any string including a thousands separator which doesn’t follow these rules is a wrong number in this culture (i.e., shouldn't be parsed as a right number). The parsing method does have all the required information (i.e., it knows that is parsing this specific culture and knows what variables define it). There is no underlying and comprehensive wisdom in the code being criticised, their creators plainly decided to not account for a somehow-complex reality properly (for whatever reason).

If you want to use a different culture, the rules might be different. Even in some cases, as pointed in previous comments, these rules might become much more complex. Even more complex than what the CultureInfo class (the one in charge of dealing with all this information) can deal with (what purely speaking would also represent a bug in such a situation). If you would have taken a look at the code I am talking about (because it might sound incredible to some of the commentators here, but not knowing anything about the code being discussed isn't precisely the ideal scenario to share your opinions on this matter), you would know that it even includes certain hardcoded rules for specific cultures! (what in my opinion should also be improved, but this is not the point now).

In summary, all what you are saying about thousands separators in general terms don't have anything to do with what I have been talking about (i.e., plainly referring to a specific/default culture; or shall I enumerate each single culture every time?!). And what is more important: no matter how complex a given situation is, it shouldn't ever represent a limitation for its proper implementation (logically, I am talking exclusively from a technical perspective).

There are sensible reasons to oppose to what I am proposing (e.g., "we don't want to make a so radical change because would affect old codes") and nonsensical ones (e.g., "this behaviour is fine" when you aren't even understanding the behaviour; or the reasons for this behaviour to exist). I respect the ones belonging to the first group, but don't want to get involved in the associated discussions anyway. Regarding the ones in the second group, I nicely ask their authors to please stop bothering me.

[varocarbas]

@RobThree Not sure if I am getting your point right, but the current CultureInfo class (the one being used by the parsing method I am criticising here and in any other situation involving culture-based formats) includes already a group size property. The aforementioned method is plainly not using this information.

In any case, note that properly accounting for the thousands separators is not the maximum level of complexity ever (it is actually pretty simple): for most of the cultures it is extremely straightforward (i.e., a small modification in the current implementation) and an additional simple correction would take care of the few exceptional behavious (or might even be ignored by the correction and keep using the old format). As explained in my previous comment, the current CultureInfo class can actually be considered faulty (i.e., not comprehensive enough): I have seen some hardcoded rules for specific cultures in the code I am referring (hardcoding = not so go structure; I guess that we all can agree on that).

[Dave3of5]

Is this a troll or is this serious ?

[AyrA]

@Dave3of5 I think this is serious. Not sure however.

[varocarbas]

Random trolling, seriously? (These last comments represent the absolute bottom; but there have been quite a few comments before on similar lines). Is this what I have to pass through to propose an improvement in the .NET Framework? Seriously?

I hope that someone in Microsoft will take a look at some of the comments in this thread (and in other ones) and think carefully whether this is the best way to allow an open-source community to exist at all. Are you expecting good-will contributors to pass through this process every time? Good luck with that (+ don't count on me).

[AyrA]

@varocarbas

Implementing a breaking change is in most cases not an improvement.

[Dave3of5]

@varocarbas Mate if you've had enough on this conversation then just stop ... You seem like a troll to me please respect MY opinion. You are making yourself look a bit silly here. Do you know this is front page on /r/programming ?

[MartinJohns]

@varocarbas You are repeatedly ignoring very valid concerns and responses, simply because they do not match what you want to hear. This is not how open source communities work.

[AyrA]

@MartinJohns He can fork it at any time and rewrite the function for himself if he wants.

[xenolightning]

Hi, I'm not sure if this is the right place; but I also have a suggestion to Console.Write. I believe that printing out grammatically incorrect sentences is wrong. It should only print out a sentence that meets the language grammar that is defined in the current CultureInfo.

[Davio]

Okay, I'm finally convinced, you've pleaded your case well, @varocarbas, please vote for and support this change and add it to the main line in the next release.

Aaah, just kidding of course. Do have to point this out though: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

[AyrA]

@xenolightning seems logical to me.

Have you tried using NumberStyles.Any as OP did and expecting it to not accept any number?

I know your issue is about strings but the number in OPs post is also a string.

[varocarbas]

Apparently, I was wrong: the bottom wasn't still reached in my previous comment (not sure how low can go some people still. Let's see... absolute ignorance + obsessive behaviours can perform really well on this front).

[RobThree]

@varocarbas

@RobThree Not sure if I am getting your point right

That was, actually, totally my bad. I replied before I read the rest of your post and later noticed you mentioned that yourself. So I ninja-edited (deleted) my post but apparently too late :stuck_out_tongue:

[Dave3of5]

@varocarbas Why don't you go back to your blog and post some comment about how stupid we all are ? I'd like to read that post, maybe share it on hackernews ?

[varocarbas]

@RobThree All clear (you might have to work a bit on improving the speed of your ninja skills :)).

[varocarbas]

@Dave3of5 My blog? What are you talking about?! I don't have any blog.

I know that trolls shouldn't be fed, but I am not used to deal with this level of crazy nonsense; that's why reading such pointless stupidities and not saying even a word is kind of difficult to me (will try harder next time).

[jloper3]

@varocarbas you don't need a "go ahead". Fork the repo, make the change as you see fit, and submit a pull request. The maintainers will simply reject or accept it. If they reject it, use your own fork of coreclr and live happily ever after.

[AyrA]

and live happily ever after.

Or learn why NumberStyles.Any accepts any number format.

[varocarbas]

@jloper3 I guess that such a behaviour will be rejected almost for sure. In any case, if I implement something (not the case yet) and am happy enough with the result, I might give it a try (nothing to lose anyway). Kind of weird suggestion, but perhaps useful. Thanks.

[varocarbas]

@AyrA This flag doesn't have any effect in the descripted problem as far as you can use any value and the referred situation would be occurring anyway (as explained many times already, the method performing the parsing actions doesn't even care about group sizes). That's why it is called bug (= against the most logical behaviour) and that's why I have started this thread (-> I have a quite relevant experience in .NET; and have seen this specific problems various times, actually I participated in a SO question precisely dealing with it; links in a comment above. I am not saying things randomly, but by knowing what I am talking about).

[Dave3of5]

@varocarbas Bear in mind not to fork the master but only a specific released version (Otherwise you are taking an in dev version of the coreclr ...). If you want to use it for yourself...

[RobThree]

I guess that such a behaviour will be rejected almost for sure.

Creating a fork and submitting a PR? That's _exactly_ what they/we/everyone want(s). It's up to the owners of the project to accept or reject the PR.

That's why it is called bug (= against the most logical behaviour)

A bug is when something says (documented or implied) to do one thing and does something else. It has nothing to do with logical behavior. If a method AddNumbers(a, b) returns -1 for arguments 2 and 3 then it _probably_ is a bug if it is documented as "Adds two numbers together" or because the method quite clearly states what it's supposed to do _unambiguously_. The (Try)Parse(...) method (in it's name) doesn't clearly specify what it does with grouping digits and also the documentation is _at the very least_ ambiguous about the cases which it accepts and/or rejects as parseable and what the results will be. And _that's_ when people start relying on _observed_ behavior (simply try it and see what it does). They probably _shouldn't_ do that but it happens. And _that's_ why you can't change such elementary things on products / libraries / frameworks (with such a large userbase) easily on a whim. It has nothing to do with "logical behaviour"; what is logical to me or you may not be logical to others. It's what's currently in the field built upon the existing behavior that matters.

As I've said before: you _can_ still have it your way by proposing something like (Try)ParseExact or (Try)ParseStrict or something; this way you don't break existing code and as an added bonus the method (just a little bit) more clearly states it's intention of being more strict that current existing (Try)Parse methods and that documentation for this method doesn't currently exists and can be written accordingly. Another option would be to add a NumberStyles.StrictThousandsSeparator or something which would allow you to keep using the existing (Try)Parse methods and _also_ make it possible to use the strict(er) behaviour. Key is that neither option changes current behavior and breaks backwards compatibility.

[Dave3of5]

@RobThree Just want to point out that this guy has a very specific copyright notice on his website with regards to the work that he does. If I was in the dotnet team I would be careful about accepting a pull request from him. That's not to say you shouldn't but just probably get a lawyer to look over the wording on his website first.

[AyrA]

@varocarbas The position of the chars is ignored for the same reason, white space or the currency symbol is ignored: it does not changes the numerical value.

You are unable to learn this, you have established that. You can try to convince us as long as you want, it is not going to happen. If the change will ever be implemented, then only in the next major release to not break existing code.

I am a quite experience programmer, what I seriously doubt that is your case

The fact, that you do not seem to understand how stupid this whole situation is speaks otherwise. Also I have certification from the Swiss government for programming. If your website is not lying, then I have also been programming a lot longer and in many more languages than you, so stop making assumptions about other people.

[varocarbas]

@RobThree "Creating a fork and submitting a PR? That's exactly what they/we/everyone want(s)" -> Seriously? And why am I here wasting so much time unnecessarily?! :) Honestly and in general terms, this has been very helpful to get a better idea about how to deal with the .NET team/the expectations of this community. Thanks to everyone again.

I might even go ahead and implement the TryParseExact approach (well... I have to take look at all this to make sure that it doesn't involve too much effort) which mgravell rightfully proved as a better alternative.

[MartinJohns]

And why am I here wasting so much time unnecessarily?!

That's the true spirit of Open Source! (⸮)

[RobThree]

Seriously? And why am I here wasting so much time unnecessarily?!

Seriously. And I don't know :stuck_out_tongue:
Go ahead and good luck! :+1: Just please don't be offended or sad when the CoreClr team decides to reject your PR for any of reasons mentioned here or possibly even other reasons we haven't even come up with / foreseen / mentioned here. Your intentions, clearly, are good. It's just that we're trying to warn you (or convince you) that your current proposed solution (changing current behavior) will most likely _not_ be accepted.

[AyrA]

@MartinJohns It can be quite interesting: https://github.com/whitehouse/fortyfour/issues/3

[varocarbas]

@MartinJohns I see. This is a good reason for not having been too active in the "movement" before :)

[varocarbas]

@AyrA You are right on the "stop making assumptions about other people" point. I apologise for my previous comment (updated it already anyway).

[MartinJohns]

@varocarbas I was being sarcastic, thus the irony punctuation mark. The spirit of Open Source is open discussion. So kinda the opposite of what you do.

[RobThree]

@everlaat Thanks for your valuable contribution!

[mgravell]

I'm sorry you feel you've had a hostile reception, and the conversation indeed isn't a model of civility. I hope you don't let it influence you to be less involved. But: I think there are some learning points here that you should take on board:

• you have dismissed some valid points raised by multiple people in the community
• you have refused to take on board repeated correction on the same themes (. vs , etc)
• you have tried to insist that only some people are entitled to have an oppinion: that is a match on a petrol can right there

There are good reasons not to accept the idea _as proposed_, and they aren't because the idea is stupid or whatever - so don't take it personally. There is some good stuff here that could be used in a different API.

[varocarbas]

@RobThree As said before, I didn't have too high hopes anyway. I understand that this kind of things are difficult (and as you can see from my attitude, I am not precisely too patient with certain behaviours, so...). We will see. Thanks again.

[atheken]

@varocarbas The correct tool for the problem you wish to solve: "validating the format of this string that might represent a number" is a Regex.

Let's try to formulate a hypothetical situation to illustrate the problem with changing framework features like Parse.

You write an app that uses a REST API. You've got strict JSON parsing on the response payload from one of their endpoints (you throw an exception if there's unexpected properties in the response payload). The REST API adds new properties to this endpoint. Your app, which has been working in production for months is now crashing.

When you wrote your app, did you have a reasonable expectation that the endpoint's behavior would not change? Did you write tests that validated the internal behavior of the API?

Of the .net applications that are out in the world, how many of them do you suppose have tests on TryParse to verify the behavior handles a case like this? My guess is very few. Writing tests to verify framework behavior at this level would be madness.

It's not even about whether the current behavior is "correct", it's about breaking existing applications that aren't checking for (and don't care) about positional commas. And, for what, because we saved a few people that had a specific formatting requirement (that is not even universally accepted) a Regex check?

No. Just no.

[jloper3]

@varocarbas that's exactly how it's supposed to work. Submit your pull request and you can debate the merit with the maintainers there. In this space your filing an issue, claiming you can fix it. Prove it by submitting a PR and end this nonsense.

[varocarbas]

@mgravell Thanks for the nice words (and in general for the comments). I do understand perfectly that my behaviour provokes certain attitudes, it was just that I thought that contributing here was a bit more of my style. To put it in terms you certainly understand: I like SO, but I don't like Meta. No problem with anyone, just that I don't want to get involved in certain situations (Meta). To know it for sure, I need to make some mistakes. This was my mistake. Anyway... again thanks.

[varocarbas]

@MartinJohns I was (kind of) sarcastic too. With "kind of" I meant that I got your idea (= how this should work), but the reality (= what I have seen here, mainly today) doesn't seem to prove it (= lots of people wasting time, getting offended and trying to offend; just a few trying to understand the underlying problem and trying to help). In any case, thanks for your contribution (I love Dr. Who).

PS: I haven't ever seen a Dr. Who episode.

[MartinJohns]

Indeed. In the reality we could not see it here. It is a pity that you chose to ignore valid points as "not technical" or "meta". :-(

Anyway, go ahead and send the pull request. The discussion will definitely repeat there.

[varocarbas]

@jloper3 You are completely right (this is precisely what I was looking for). Sorry for having contributed to create this small chaos.

[varocarbas]

@MartinJohns Just to let one point completely clear: I never wanted to ignore anything. But do you have an idea of how much time I have been wasting here between yesterday and today (in 3 threads I have been participating)? How many comments repeating basically the same things I have got? I was nice to everyone during the first 2-3 hours, then I got tired.

Understand that I do respect everyone's approach, but I am free to prefer certain discussions; why should I participate in what I don't want to participate? When you force me to talk about something I don't want, you are the one not respecting me.

As said: thanks to everyone and sorry if I have offended some people (it wasn't my intention).

[MartinJohns]

You don't need to participate in what you don't want to participate in. But by responding you chose to participate, you chose to respond and to react. Like I said in the other issue already: You may have raised this issue, but that doesn't mean you own it. It doesn't mean the discussion goes only according to your preference.

And frankly, I don't see any point in submitting a PR before the discussion was resolved here. If you just submit a PR now, then the discussion will just repeat in your pull request. What's the point of that? You said you don't want to waste your time, yet you do it.

[Dave3of5]

@varocarbas Well looks like you are coming to your senses, maybe you aren't a troll after all. Seriously though I would just stop replying to this issue if I was you just ignore everything here. Try to learn from this.

[jloper3]

@varocarbas The free market of ideas can sometimes be chaotic, but mostly produces the best outcomes. This is the spirit of open source. It is not just a technical movement, but cultural as well. Welcome to the community.

[lostdj]

It looks to me that the issue really is a language / culture (ironically) barrier. He failed to express his intentions / others failed to understand him in that he is _not_ after changing a known behavior and thus breaking every code ever written using this method. And he's not after any politics, nor he's accustomed to the processes taking place in this community to start a discussion on something, or propose a change or addition.

What he's after, is a discussion on how to implement something like ParseExact, with all the possible options available to configure the parser, etc. Also see @atheken comment: https://github.com/dotnet/coreclr/issues/2285#issuecomment-163937612

Eh, miscommunication happens. :)

[zao]

I wonder, can this be rephrased into a documentation enhancement request?

Should the function docs mention closer what the actual de-facto implementation does, guaranteeing that people that rely on observed behaviour (eliding group separators) has a guarantee that it continues to be so?

We've already established that the function contract cannot be changed due to demonstrated reliance on the behaviour. Should it be changed to explicitly state this instead of relying on happenstance?

[ghost]

Should we also submit a proposal to ECMAScript as JavaScript does:

parseInt("1.2,2")
> 1

parseFloat("1,2,3.4")
> 1

Is this a bug in JavaScript? Python and Ruby also possess similar relaxation in numeric parsing.

wasting time

has been said enormous amount of time in this thread by OP, which is pretty ridiculous.

language / culture (ironically) barrier.

Given the OP's attitude towards others, this is a moot point. Every human on planet should have a sense of realization and some kind of tolerance for others' opinion. Failing to possess this basic human quality is your fault. Don't blame your culture for it or use it as excuse. You know exactly what you are saying when you repeat it so many times.

[Dave3of5]

@varocarbas Just a thought, why not add this as an extension method? I believe this is the entire reason these where created. You can add your own TryParse without screwing with the CLR. Then you can stick to using the standard CLR and your application will be able to have the functionality you provided. I think for you this would be a MUCH better solution than forking this repo and creating you own version of the CLR.

[varocarbas]

@Dave3of5 Not interested (I don't need this functionality for anything; if I need it I would have created it. When I see a problem, I solve it rather than involving others on it. In fact and as already commented various times, I rarely deal with thousands separators myself. The whole point of my proposal was pointing out something which some people might find interesting, according to my experience fixing others' problems, for example in Stack Overflow. I will most likely create a new TryParseExact method and fork/pull as suggested in various comments, although not sure when).

Thanks for the comment, but I would prefer to stop participating here if you don't mind (lots of comments already).

[varocarbas]

@MartinJohns Seriously?!

Logically, the right interpretation of my comment is: "please, stop talking to me I am trying to be respecful and don't think that ignoring someone who talks to you, tries to help (kind of) you in some way, is too respectful; but I will do it anyway because I am quite tired of nonsense". I was just trying to be polite. My bad. Sorry about that.

[varocarbas]

I was starting to wonder about the reason for so many comments whose motivation wasn't too clear (and mainly coming from people whose knowledge was clearly limited on this front); also about the curious raise of visits to my web. By looking at the origin of the visitors, I reached discovered this: https://www.reddit.com/r/programming/comments/3w9tc8/a_perfect_example_of_how_not_to_propose_a_change/

I have to recognise that I am kind of honoured (why nobody told me about it?!), this is the first time that anyone has created a whole thread just for me! I mean... I don't use Reddit, but it is kind of relevant (and there are lots of comments). Thanks fans. Sorry about that, but you hero doesn't care too much about you (no, I will not even read what you have written, because after seeing the comments here I don't too much there) ;)

Microsoft, I do recognise that I am a magnet for this kind of reactions (although seriously that this is the first time when I have provoked such a thing!), but I hope that everyone will learn from this "incident". I personally will focus my activity on mere fork/pull-ing (and eventually post very small answers/questions).

[canton7]

(why nobody told me about it?!)

@varocarbas: @RobThree linked the reddit post 17 hours ago.

[varocarbas]

@canton7 Thanks for the clarification, I did skim through that specific comment (as said, many comments saying basically the same + me not feeling like chatting & getting tired = lots of information wasn't properly assimilated), but assumed that it was a random Reddit chat (I did find kind of curious that one of the referred comments was almost quoting my own words, but didn't give too much importance it and thought that was a RobThree mistake while writing it). Not a whole thread with lots comments completely focused on me!!!

Anyway... not too important. But this has certainly been a curious final note (to a very curious first open .NET experience). First times are usually not too funny in the moment, but later you look at them differently (I am starting to enjoy already this one) :)

[Dave3of5]

Lol what a tool.

[varocarbas]

@Dave3of5 Ey, stupid, I can laugh at you (at your ignorance and at your lack of capability to understand even the simplest idea) and let you think that you have everything under control. But, piece of shit, don't ever dare to insult me when I am present.

You can now go back with your friends (the idiots/cowards who take you seriously) to talk about me behind my back; and then, eventually, get a bit of courage to say something ambiguous enough to me, and perhaps I will tolerate it, but this is it. Idiot.

Go back to Reddit, to deal with people saying stupid things in low voice and behind my back, where you belong.

[canton7]

@varocarbas let me put this cleanly, so there is no chance of misunderstanding.

The issue is not with people failing to understand you. It is:

1. You assert that "1,1.1" is "obviously" not a valid decimal, and fail to respond to the assertions to the contrary.
2. You assert that breaking backwards compatibility here is not important (when it is) and ignore assertions to the contrary.

People on the internet get wound up when they see other people behaving like this: that's just what happens.

The fact that this happened in a coreclr / .NET thread is irrelevant: it would have happened anywhere. This just happens to be a repository which lots of people watch.

[Dave3of5]

Ok I guess I deserved that I'll leave now bye :-)

[varocarbas]

@canton7 The problem here was that I didn't want to participate in certain discussion, what some people didn't like. Better: some people didn't like me being very clear on this and other fronts (and got offended when this wasn't ever my intention). I wanted to plainly propose something (to eventually do some tests and prove some points but only from a technical point of view) and to let the analysis of further issues and the final decision to others (i.e., Microsoft and/or the community not including me).

I should have plainly written the code, done a simple fork/pull request and nothing else. I made a mistake. Lesson learned (= from now on more forking/pulling and less talking).

[MartinJohns]

The problem here was that I didn't want to participate in certain discussion, what some people didn't like.

Again: You do not choose what direction the discussion goes. The discussion goes towards all aspects that the proposed change would affect.

And sentences like this are really unneeded:

and mainly coming from people whose knowledge was clearly limited on this front

Many of the people posted here have a much broader knowledge than you.

[richlander]

This thread has turned into more of a chat room on compatibility. Definitely a good topic, but this isn't really the best forum for it. Feel free to use the .NET Foundation Forums for this discussion or I see that Reddit has a thread going on this topic. I'm going to close this issue as a result.

I think that the community has largely spoken on this topic. A brief summary, plus some small additions:

We're not going to make breaking changes to existing APIs, except in the rare case for security. Where we want to change the behavior of an existing API, we can always add a new one and that's a fine conversation. We need to balance evolution and stability.

On the particular topic of formats and culture, please do refer as much as possible to industry specs to justify and provide weight to proposals. Discussions on these type of topics w/o authoritative sources quickly devolve as this one has. Internally, we have people with ECMA 334/335, Unicode, HTTP and various chip specs on their desks. They often 'argue' in terms of those specs. It's a good approach to follow.

Pointers on the contribution guidelines: Overall Guidelines and Managed Code Compatibility.

Have a great weekend!