Decimal type not able to parse scientific notation #2290

Closed
varocarbas opened this Issue Dec 10, 2015 · 23 comments

Comments

Projects
None yet
@varocarbas
Contributor

varocarbas commented Dec 10, 2015

The problem is shown in the following code:

Double doubleVal = 0.0;
if (Double.TryParse("1E-05", out doubleVal))
{
    //This part is reached because Double can parse scientific notation
}

Decimal decVal = 0m;
if (Decimal.TryParse("1E-05", out decVal))
{
    //This part isn't reached because Decimal cannot parse scientific notation
}

The solution should be straightforward (i.e., already a working-version in a similar type). Additionally, note that I am somehow familiarised with this part of the code because of being currently involved in other Decimal parsing issue (#2285).

@varocarbas

This comment has been minimized.

Show comment
Hide comment
@varocarbas

varocarbas Dec 10, 2015

Contributor

Still new and still not sure what I should do now. Ready to fix as soon as I will get a "go ahead".

Contributor

varocarbas commented Dec 10, 2015

Still new and still not sure what I should do now. Ready to fix as soon as I will get a "go ahead".

@akoeplinger

This comment has been minimized.

Show comment
Hide comment
@varocarbas

This comment has been minimized.

Show comment
Hide comment
@varocarbas

varocarbas Dec 10, 2015

Contributor

@akoeplinger Good point. The example I propose does work in case of using an overload allowing to account for System.Globalization.NumberStyles.Float.

On the other hand, is such behaviour something which the intuitive .NET Framework should have? For example: Decimal.Parse can deal without any problem with "1.2"; even though and purely speaking this is a Double literal. Why making an arbitrary difference between this situation and the aforementioned one? Isn't the whole point of a parsing method to be as flexible as possible and to anticipate what the programmer wants (within what might be considered correct)?

In summary: I do think that something like "1E-05" should be immediately understood as a number by any parsing method, exactly the same than "1.2" (logically, by assuming that "." is the decimal separator in the given culture). In fact, I realised about this issue while answering a SO question where someone was complaining about such an issue (i.e., some programmers are likely to be in this situation and to not find the solution right away). Additionally, it would be a quite straightforward correction, why not doing it?

Contributor

varocarbas commented Dec 10, 2015

@akoeplinger Good point. The example I propose does work in case of using an overload allowing to account for System.Globalization.NumberStyles.Float.

On the other hand, is such behaviour something which the intuitive .NET Framework should have? For example: Decimal.Parse can deal without any problem with "1.2"; even though and purely speaking this is a Double literal. Why making an arbitrary difference between this situation and the aforementioned one? Isn't the whole point of a parsing method to be as flexible as possible and to anticipate what the programmer wants (within what might be considered correct)?

In summary: I do think that something like "1E-05" should be immediately understood as a number by any parsing method, exactly the same than "1.2" (logically, by assuming that "." is the decimal separator in the given culture). In fact, I realised about this issue while answering a SO question where someone was complaining about such an issue (i.e., some programmers are likely to be in this situation and to not find the solution right away). Additionally, it would be a quite straightforward correction, why not doing it?

@akoeplinger

This comment has been minimized.

Show comment
Hide comment
@akoeplinger

akoeplinger Dec 10, 2015

Member

I have no idea why it was implemented that way, hopefully someone from the .NET team can chime in and provide more details. Number parsing is a complex topic 😄

Additionally, it would be a quite straightforward correction, why not doing it?

The biggest reason is that it would be a change in behavior.

Member

akoeplinger commented Dec 10, 2015

I have no idea why it was implemented that way, hopefully someone from the .NET team can chime in and provide more details. Number parsing is a complex topic 😄

Additionally, it would be a quite straightforward correction, why not doing it?

The biggest reason is that it would be a change in behavior.

@varocarbas

This comment has been minimized.

Show comment
Hide comment
@varocarbas

varocarbas Dec 10, 2015

Contributor

@akoeplinger I guess that "change in behaviour" should only be defended when removing a feature which might be used by someone. But including a feature which nobody was using (i.e., nobody has been parsing scientific notation to decimal directly, because it was never impossible) shouldn't be a problem.

Anyway... thanks for your insights. Yesterday, I saw both CoreCLR and CoreFX for the first time and I am feeling like changing so many things!! What a marvellous resource!! :)

Contributor

varocarbas commented Dec 10, 2015

@akoeplinger I guess that "change in behaviour" should only be defended when removing a feature which might be used by someone. But including a feature which nobody was using (i.e., nobody has been parsing scientific notation to decimal directly, because it was never impossible) shouldn't be a problem.

Anyway... thanks for your insights. Yesterday, I saw both CoreCLR and CoreFX for the first time and I am feeling like changing so many things!! What a marvellous resource!! :)

@akoeplinger

This comment has been minimized.

Show comment
Hide comment
@akoeplinger

akoeplinger Dec 10, 2015

Member

@varocarbas there might well be code out there that relies on getting false when trying to parse numbers in scientific notation, so it's a change in behavior regardless ;)

Member

akoeplinger commented Dec 10, 2015

@varocarbas there might well be code out there that relies on getting false when trying to parse numbers in scientific notation, so it's a change in behavior regardless ;)

@varocarbas

This comment has been minimized.

Show comment
Hide comment
@varocarbas

varocarbas Dec 10, 2015

Contributor

@akoeplinger But these persons deserve to get an error because of having implemented a so illogical approach. LOL.

Contributor

varocarbas commented Dec 10, 2015

@akoeplinger But these persons deserve to get an error because of having implemented a so illogical approach. LOL.

@mikedn

This comment has been minimized.

Show comment
Hide comment
@mikedn

mikedn Dec 10, 2015

Contributor

For example: Decimal.Parse can deal without any problem with "1.2"; even though and purely speaking this is a Double literal.

1.2 is a double literal in the context of a language like C#. The idea of a "double literal" makes no sense in the context of BCL's parsing.

Why making an arbitrary difference between this situation and the aforementioned one?

Why is this difference arbitrary? decimal and floating point types are very different in terms of functionality and use. If you go to a bank and write 1E5 on a check you'll probably get some strange looks.

Contributor

mikedn commented Dec 10, 2015

For example: Decimal.Parse can deal without any problem with "1.2"; even though and purely speaking this is a Double literal.

1.2 is a double literal in the context of a language like C#. The idea of a "double literal" makes no sense in the context of BCL's parsing.

Why making an arbitrary difference between this situation and the aforementioned one?

Why is this difference arbitrary? decimal and floating point types are very different in terms of functionality and use. If you go to a bank and write 1E5 on a check you'll probably get some strange looks.

@varocarbas

This comment has been minimized.

Show comment
Hide comment
@varocarbas

varocarbas Dec 10, 2015

Contributor

@mikedn Considering 1E5 a double, but not a decimal is arbitrary. Exactly the same that considering 1.2 the string literal of double; but, as you are rightly pointing out, this issue is not relevant when parsing. The only relevant thing when parsing is meeting the min/max limits. That's why all the parsers should immediately understand 1.2 (the ones with decimal capabilities) and 1E5 as numbers.

BTW, this implementations has a stll lower impact than the other one you are criticising; and is already being performed (my suggestion only aims to extend its applicability to all the possible scenarios).

Contributor

varocarbas commented Dec 10, 2015

@mikedn Considering 1E5 a double, but not a decimal is arbitrary. Exactly the same that considering 1.2 the string literal of double; but, as you are rightly pointing out, this issue is not relevant when parsing. The only relevant thing when parsing is meeting the min/max limits. That's why all the parsers should immediately understand 1.2 (the ones with decimal capabilities) and 1E5 as numbers.

BTW, this implementations has a stll lower impact than the other one you are criticising; and is already being performed (my suggestion only aims to extend its applicability to all the possible scenarios).

@mikedn

This comment has been minimized.

Show comment
Hide comment
@mikedn

mikedn Dec 10, 2015

Contributor

Considering 1E5 a double, but not a decimal is arbitrary.

And I already asked you why so we're back at square one :)

Contributor

mikedn commented Dec 10, 2015

Considering 1E5 a double, but not a decimal is arbitrary.

And I already asked you why so we're back at square one :)

@mellinoe

This comment has been minimized.

Show comment
Hide comment
@mellinoe

mellinoe Dec 10, 2015

Contributor

@akoeplinger But these persons deserve to get an error because of having implemented a so illogical approach. LOL.

It's a nice idea, but unfortunately we really don't have the luxury of making breaking changes like this at a whim. We have a more nuanced policy than "just fix it" when there's billions of PC's with Windows installed which are depending on the consistent behavior of low-level API's, and for those to not change underneath them (yes, even in a way that "makes more sense" than before).

If we want to make changes like this, we have to put some sort of compatibility shim in place so that older consumers get the old behavior and new consumers get the new behavior. I think we usually reserve that sort of thing for very important bug fixes.

Contributor

mellinoe commented Dec 10, 2015

@akoeplinger But these persons deserve to get an error because of having implemented a so illogical approach. LOL.

It's a nice idea, but unfortunately we really don't have the luxury of making breaking changes like this at a whim. We have a more nuanced policy than "just fix it" when there's billions of PC's with Windows installed which are depending on the consistent behavior of low-level API's, and for those to not change underneath them (yes, even in a way that "makes more sense" than before).

If we want to make changes like this, we have to put some sort of compatibility shim in place so that older consumers get the old behavior and new consumers get the new behavior. I think we usually reserve that sort of thing for very important bug fixes.

@varocarbas

This comment has been minimized.

Show comment
Hide comment
@varocarbas

varocarbas Dec 10, 2015

Contributor

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.

Contributor

varocarbas commented Dec 10, 2015

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.

@RobThree

This comment has been minimized.

Show comment
Hide comment
@RobThree

RobThree Dec 11, 2015

What you're not understanding is that your proposed changes are breaking changes. People, competent or not, are relying on some behaviours knowingly or sometimes maybe even _un_knowingly.

As a simple (maybe a bit contrived but stick with me) example: you can imagine someone programming a textbox desiring an input from 0 to 999. So they set the MaxLength property to 3 and be done with it; letters and other characters will fail and be handled accordingly. Then they pass the user's input trough double.Parse since they need a double a few lines down (so going through int.Parse and then casting to double is the long way around) and are quite confident the input is anything from 0 to 999. Now you come along and change this behaviour and suddenly a user can input 1e9. The ramifications can be anything from maybe only a shoesize now being way of the charts or maybe you've opened the gates to hell and introduced a security issue (similar to, for example, a buffer overflow).

Yes, the programmer using such an approach should've done a more rigorous and decent job and yes there's a lot wrong in this example. And, yet, maybe that program has actually sold millions of copies and now suddenly millions of people are affected just because someone decided to change the behavior. The (your) intentions are (or were) good, the side-effects however are bad.

Such changes require, as proposed, shims, maybe even a (new overload with a) extra argument to the (Try)Parse methods that allow you to specify the desired behavior or maybe even a whole new method needs to be created (e.g. (Try)ParseScientific(...) or something similar).

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.

What you're not understanding is that your proposed changes are breaking changes. People, competent or not, are relying on some behaviours knowingly or sometimes maybe even _un_knowingly.

As a simple (maybe a bit contrived but stick with me) example: you can imagine someone programming a textbox desiring an input from 0 to 999. So they set the MaxLength property to 3 and be done with it; letters and other characters will fail and be handled accordingly. Then they pass the user's input trough double.Parse since they need a double a few lines down (so going through int.Parse and then casting to double is the long way around) and are quite confident the input is anything from 0 to 999. Now you come along and change this behaviour and suddenly a user can input 1e9. The ramifications can be anything from maybe only a shoesize now being way of the charts or maybe you've opened the gates to hell and introduced a security issue (similar to, for example, a buffer overflow).

Yes, the programmer using such an approach should've done a more rigorous and decent job and yes there's a lot wrong in this example. And, yet, maybe that program has actually sold millions of copies and now suddenly millions of people are affected just because someone decided to change the behavior. The (your) intentions are (or were) good, the side-effects however are bad.

Such changes require, as proposed, shims, maybe even a (new overload with a) extra argument to the (Try)Parse methods that allow you to specify the desired behavior or maybe even a whole new method needs to be created (e.g. (Try)ParseScientific(...) or something similar).

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.

@varocarbas

This comment has been minimized.

Show comment
Hide comment
@varocarbas

varocarbas Dec 11, 2015

Contributor

@RobThree If you want to systematically rely on these ideas ("better don't correct anything because might provoke the craziest code to crash"), you wouldn’t ever modify old functionalities. Such an attitude would represent serious restrictions in the adaptability of the final product (which theoretically aims to be as adaptable as possible). It would represent an extremely static attitude whose main goal wouldn’t be to evolve/adapt/improve, but to plainly focus on proving that the errors are actually not so bad. In fact, this has happened already in the recent past (i.e., VB6 and .NET): relying on not-too-good (or plainly wrong) approaches for as long as possible, focusing on maximising your monopolistic position (i.e., Windows) and then moving away to a different (objectively better) format only when strictly required. Do you want to continue like this? Who am I to correct you? You are extremely big and your product is certainly good. Although I might wonder about the exact essence of your “open source“ attitude: the code is there (and I have it and I will certainly use it for my personal joy; thanks again, Microsoft, you have made me really happy :)), but is the product really open source if no changes can be performed? Or no need to go so far: I might plainly decide that the main guidelines of this project do not meet my expectations and might not want to participate in it.

Is there a real backwards-compatibility problem with what I am suggesting here? Saying that there will be not even a single problem would be lying; nobody can tell this for sure. On the other hand, you have to draw the line at some point and not supporting bad coding practices (or user misbehaviours) seems like a good place to start. In the example you are proposing, a user inputs “1e5” in a textbox where he is expected to input a number and the application crashes; would this user rightfully feel bad about it? In a generic piece of software which is not too adaptable and has tons of limitations? I don’t think so. In a highly adaptable program perfectly understanding any user input? Users would certainly expect these applications to work fine anyway; but in that scenario, the given programmers would have taken care of this and many other issues already (i.e., you cannot build a highly adaptable piece of software by blindly trusting in what the given programming language delivers, mainly when talking about not-too-clear functionalities).

The proposed modification has a very little impact at all the levels and represents the kind of logical, intuitive and consistent behaviour which the .NET languages are expected to deliver. The fact of having 2 types like Double and Decimal with different overloads and only some of them supporting certain format (scientific notation) doesn't make any sense. Not within an intuitive and reliable enough framework.

In any case and as explained in my other thread (the one you are linking above), I am certainly not interested in coming into this kind of discussions. You are free to discuss as much as you want about all these issues and to make your final decisions upon any issue. But please don't think that you can convince me of something about which my ideas are crystal clear (i.e., my most basic convictions regarding how this kind of problems should be faced); I am not trying to convince you either (just to understand if you are willing to deliver what I am willing to accept or not). Think carefully about all the involved issues, discuss for as long as you wish (but try to not involve me in your discussions unless when dealing with strictly technical issues), make whatever decision and let me know about it.

Contributor

varocarbas commented Dec 11, 2015

@RobThree If you want to systematically rely on these ideas ("better don't correct anything because might provoke the craziest code to crash"), you wouldn’t ever modify old functionalities. Such an attitude would represent serious restrictions in the adaptability of the final product (which theoretically aims to be as adaptable as possible). It would represent an extremely static attitude whose main goal wouldn’t be to evolve/adapt/improve, but to plainly focus on proving that the errors are actually not so bad. In fact, this has happened already in the recent past (i.e., VB6 and .NET): relying on not-too-good (or plainly wrong) approaches for as long as possible, focusing on maximising your monopolistic position (i.e., Windows) and then moving away to a different (objectively better) format only when strictly required. Do you want to continue like this? Who am I to correct you? You are extremely big and your product is certainly good. Although I might wonder about the exact essence of your “open source“ attitude: the code is there (and I have it and I will certainly use it for my personal joy; thanks again, Microsoft, you have made me really happy :)), but is the product really open source if no changes can be performed? Or no need to go so far: I might plainly decide that the main guidelines of this project do not meet my expectations and might not want to participate in it.

Is there a real backwards-compatibility problem with what I am suggesting here? Saying that there will be not even a single problem would be lying; nobody can tell this for sure. On the other hand, you have to draw the line at some point and not supporting bad coding practices (or user misbehaviours) seems like a good place to start. In the example you are proposing, a user inputs “1e5” in a textbox where he is expected to input a number and the application crashes; would this user rightfully feel bad about it? In a generic piece of software which is not too adaptable and has tons of limitations? I don’t think so. In a highly adaptable program perfectly understanding any user input? Users would certainly expect these applications to work fine anyway; but in that scenario, the given programmers would have taken care of this and many other issues already (i.e., you cannot build a highly adaptable piece of software by blindly trusting in what the given programming language delivers, mainly when talking about not-too-clear functionalities).

The proposed modification has a very little impact at all the levels and represents the kind of logical, intuitive and consistent behaviour which the .NET languages are expected to deliver. The fact of having 2 types like Double and Decimal with different overloads and only some of them supporting certain format (scientific notation) doesn't make any sense. Not within an intuitive and reliable enough framework.

In any case and as explained in my other thread (the one you are linking above), I am certainly not interested in coming into this kind of discussions. You are free to discuss as much as you want about all these issues and to make your final decisions upon any issue. But please don't think that you can convince me of something about which my ideas are crystal clear (i.e., my most basic convictions regarding how this kind of problems should be faced); I am not trying to convince you either (just to understand if you are willing to deliver what I am willing to accept or not). Think carefully about all the involved issues, discuss for as long as you wish (but try to not involve me in your discussions unless when dealing with strictly technical issues), make whatever decision and let me know about it.

@jakesays

This comment has been minimized.

Show comment
Hide comment
@jakesays

jakesays Dec 11, 2015

@varocarbas I think the point you are missing is the issues we raise against your ideas ARE objective by any rational definition of the word.

@varocarbas I think the point you are missing is the issues we raise against your ideas ARE objective by any rational definition of the word.

@Havvy

This comment has been minimized.

Show comment
Hide comment
@Havvy

Havvy Dec 11, 2015

Stability as a guarantee means you cannot make breaking changes - and those are changes that possibly change the meaning of an already existing program. Given the widespread adoption and age of the CLR, and especially these methods, you have to be really careful about changing anything.

You can try creating a new set of functions that operates differently, but it's usually best to show that those functions are useful in the outer ecosystem before adding them to the standard library.

Nobody from Microsoft is actually commenting yet AFAICT. Everybody here (except me really) are developers who use the CLR platform. But we do understand that you're not going to get a "go ahead" because of the stability guarantee.

When you say very little impact, you are thinking about the billions of lines of code written for the CLR. A small impact on such a widespread codebase has huge consequences. If you want real low impact changes that are breaking and would be considered, it would be soundness fixes (e.g. type system bugs - should be really rare given CLR's age), changing the meaning of nonsensical statements (e.g., making something that compiles by accident an error), changing a method to have improved time/space characteristics, and other similar changes. Changing what it returns is the opposite, as a developer cannot write anything stable if functions change their meaning over time. On the other hand, a programmer cannot use a method that does not exist, so adding methods is usually fine. There's exceptions to that as well. If a library is using the lack of a capability from a certain class, adding that capability breaks the library. All in all, stability is an extremely tricky thing to deliver. But it's a necessary one. It's also the reason why there will always be new platforms in the future.

Havvy commented Dec 11, 2015

Stability as a guarantee means you cannot make breaking changes - and those are changes that possibly change the meaning of an already existing program. Given the widespread adoption and age of the CLR, and especially these methods, you have to be really careful about changing anything.

You can try creating a new set of functions that operates differently, but it's usually best to show that those functions are useful in the outer ecosystem before adding them to the standard library.

Nobody from Microsoft is actually commenting yet AFAICT. Everybody here (except me really) are developers who use the CLR platform. But we do understand that you're not going to get a "go ahead" because of the stability guarantee.

When you say very little impact, you are thinking about the billions of lines of code written for the CLR. A small impact on such a widespread codebase has huge consequences. If you want real low impact changes that are breaking and would be considered, it would be soundness fixes (e.g. type system bugs - should be really rare given CLR's age), changing the meaning of nonsensical statements (e.g., making something that compiles by accident an error), changing a method to have improved time/space characteristics, and other similar changes. Changing what it returns is the opposite, as a developer cannot write anything stable if functions change their meaning over time. On the other hand, a programmer cannot use a method that does not exist, so adding methods is usually fine. There's exceptions to that as well. If a library is using the lack of a capability from a certain class, adding that capability breaks the library. All in all, stability is an extremely tricky thing to deliver. But it's a necessary one. It's also the reason why there will always be new platforms in the future.

@varocarbas

This comment has been minimized.

Show comment
Hide comment
@varocarbas

varocarbas Dec 11, 2015

Contributor

@Havvy Thanks for your inputs. I do get what you mean, but you should understand that I cannot be answering here each single comment (lots of them) mainly when this wasn't my intention in a first moment.

You have to bear in mind that this specific suggestion has a really little impact as far as is already being supported (by Double and by various overloads of Decimal); and that's why I don't think that general not-breaking-old-codes ideas are not fully applicable here.

Anyway and as said, please understand that I don't want to discuss about certain issues.

Contributor

varocarbas commented Dec 11, 2015

@Havvy Thanks for your inputs. I do get what you mean, but you should understand that I cannot be answering here each single comment (lots of them) mainly when this wasn't my intention in a first moment.

You have to bear in mind that this specific suggestion has a really little impact as far as is already being supported (by Double and by various overloads of Decimal); and that's why I don't think that general not-breaking-old-codes ideas are not fully applicable here.

Anyway and as said, please understand that I don't want to discuss about certain issues.

@RobThree

This comment has been minimized.

Show comment
Hide comment
@RobThree

RobThree Dec 11, 2015

You keep saying "really little impact" and we keep trying to tell you that the impact is not as "little" as you think / pretend. Maybe the impact on the .Net framework is "little" (probably even non-existing) but you need to be reminded that there are literally thousands and thousands of applications on millions and millions of computers with millions and millions of users relying on this framework. Even if .01% of the applications (knowingly or unknowingly) rely on this behavior that would mean a shitstorm of bugreports (or planes falling from the sky or...) just because someone thought "hey, let's change this behaviour for no actual benefit at all, just because I think this parsing thingy should be more strict". That's not how this works; end-of-story.

What you do in your own applications: all up to you. Go nuts. It's your customerbase. But (especially large (in userbase terms)) libraries / frameworks don't. work. that. way. (at least, if you're a responsible developer).

You keep saying "really little impact" and we keep trying to tell you that the impact is not as "little" as you think / pretend. Maybe the impact on the .Net framework is "little" (probably even non-existing) but you need to be reminded that there are literally thousands and thousands of applications on millions and millions of computers with millions and millions of users relying on this framework. Even if .01% of the applications (knowingly or unknowingly) rely on this behavior that would mean a shitstorm of bugreports (or planes falling from the sky or...) just because someone thought "hey, let's change this behaviour for no actual benefit at all, just because I think this parsing thingy should be more strict". That's not how this works; end-of-story.

What you do in your own applications: all up to you. Go nuts. It's your customerbase. But (especially large (in userbase terms)) libraries / frameworks don't. work. that. way. (at least, if you're a responsible developer).

@varocarbas

This comment has been minimized.

Show comment
Hide comment
@varocarbas

varocarbas Dec 11, 2015

Contributor

@RobThree Sorry but I will try to stick to my original intention of plainly not replying to certain comments because all this stopped making sense long time ago. You keep talking generally and repeating abstract ideas without wanting to properly understand the specific situation (and what is more important: without respecting my numerous petitions of "please, discuss all what you want; but don't involve/try to convince me").

Contributor

varocarbas commented Dec 11, 2015

@RobThree Sorry but I will try to stick to my original intention of plainly not replying to certain comments because all this stopped making sense long time ago. You keep talking generally and repeating abstract ideas without wanting to properly understand the specific situation (and what is more important: without respecting my numerous petitions of "please, discuss all what you want; but don't involve/try to convince me").

@MartinJohns

This comment has been minimized.

Show comment
Hide comment
@MartinJohns

MartinJohns Dec 11, 2015

@varocarbas Please understand that this is not a one-way street where you can decide where the conversation and discussion goes. If you don't like the way this discussion goes, please refrain from further responding. Even when you raised this issue it does not mean it is your issue alone.

@varocarbas Please understand that this is not a one-way street where you can decide where the conversation and discussion goes. If you don't like the way this discussion goes, please refrain from further responding. Even when you raised this issue it does not mean it is your issue alone.

@AyrA

This comment has been minimized.

Show comment
Hide comment
@AyrA

AyrA Dec 11, 2015

@MartinJohns he just has to use NumberStyles.AllowExponent in TryParse

AyrA commented Dec 11, 2015

@MartinJohns he just has to use NumberStyles.AllowExponent in TryParse

@bentasker

This comment has been minimized.

Show comment
Hide comment
@bentasker

bentasker Dec 11, 2015

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,

In a project the size of CLR, there's far more expertise than that required for proper management. I was reminded of a quote recently

The correct answer is not always the best technical solution

Which is where b/c breaking fixes fall.

Even in an OSS environment, you need to keep a business mind about it.

You can argue that at a technical level, the correct way would be to have consistent behaviour between Decimal and Double but if implementing that change breaks your "Customer's" applications then it's not a change you can make - even if you can argue at a technical level that those customers are idiots for relying on broken behaviour, breaking their apps isn't something that'll go down well unless you've got an incredibly strong justification.

One ill-considered small "improvement" can cause millions of developers headaches, and potentially cost businesses and people a lot of money.

As an incredibly simplistic example, imagine trying to transfer 135 in your Internet banking, and you accidentally enter 1e5. The current behaviour would return false, with your change the user would be looking at a fairly sizeable overdraft request.

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,

In a project the size of CLR, there's far more expertise than that required for proper management. I was reminded of a quote recently

The correct answer is not always the best technical solution

Which is where b/c breaking fixes fall.

Even in an OSS environment, you need to keep a business mind about it.

You can argue that at a technical level, the correct way would be to have consistent behaviour between Decimal and Double but if implementing that change breaks your "Customer's" applications then it's not a change you can make - even if you can argue at a technical level that those customers are idiots for relying on broken behaviour, breaking their apps isn't something that'll go down well unless you've got an incredibly strong justification.

One ill-considered small "improvement" can cause millions of developers headaches, and potentially cost businesses and people a lot of money.

As an incredibly simplistic example, imagine trying to transfer 135 in your Internet banking, and you accidentally enter 1e5. The current behaviour would return false, with your change the user would be looking at a fairly sizeable overdraft request.

@richlander

This comment has been minimized.

Show comment
Hide comment
@richlander

richlander Dec 12, 2015

Member

This issue has turned into a general conversation. As a result, I'm closing the issue, since there is nothing for the team to act on.

See #2285 (comment) for more insight.

Member

richlander commented Dec 12, 2015

This issue has turned into a general conversation. As a result, I'm closing the issue, since there is nothing for the team to act on.

See #2285 (comment) for more insight.

@richlander richlander closed this Dec 12, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment