How to avoid “-0” as double.ToString() result after porting from .NET Framework 4.7.2 to .NET5.0?

[jrscm]

I am porting a .NET Framework 4.7.2 Visual Studio project to .NET5.0 and I am experiencing a different behaviour of double.ToString when the value is negative and close to zero.

For example, the double value -7.1054273576010019E-15 when converted to string returns "-0" even if I round it before the conversion while with the .NET Framework 4.7.2 its result was "0" (same code).

This difference is discussed here https://devblogs.microsoft.com/dotnet/floating-point-parsing-and-formatting-improvements-in-net-core-3-0/ but I don't really agree that this is an improvement as the title states, I believe 0 should not have a sign, it is neither a positive number nor a negative number.

I know I can create a custom IFormatProvider or an extension method and convert the double as I want but this requires a change in every conversion in the code and also any developers working on the project will need to use it in the future. In my opionion this solution is not very intuitive and it's likely to be source of errors.

Is there a way to restore the previous behaviour with less effort? Is Microsoft willing to change this in the future versions of the .NET?

[huoyaoyuan]

I believe 0 should not have a sign, it is neither a positive number nor a negative number

IEEE754 standard says that it has sign. .NET BCL is conforming the standard.

Is there a way to restore the previous behaviour with less effort? Is Microsoft willing to change this in the future versions of the .NET?

The answer should be no. We won't change a standard-conform behaviour to non conformant.

[huoyaoyuan]

Instead, "no action" can satisfy everyone

It may not. I'm tired of writing ToString(CultureInfo.InvariantCulture) everywhere.

[marcocecchiscmgroup]

Instead, "no action" can satisfy everyone

It may not. I'm tired of writing ToString(CultureInfo.InvariantCulture) everywhere.

This is a little bit detouring from the original issue, anyhow, I shall consider it yet another confirmation: what culture will ever accept -0.00 as a valid number?

[huoyaoyuan]

Since I'm not the one made the decision, I can't know all their concerns. @tannergooding could you help explaining more here?

[marcocecchiscmgroup]

Since I'm not the one made the decision, I can't know all their concerns. @tannergooding could you help explaining more here?

Thanks for taking care. Waiting.

[tannergooding]

To start, there is a lot of discussion in here and I'd like to remind everyone to please keep such discussion friendly and to follow the Code of Conduct: https://dotnetfoundation.org/about/code-of-conduct

---

Breaking changes are frustrating, but they are also made for a reason. In this scenario there is a formal specification that dictates our own requirements: IEEE 754. Additionally, we had been getting a steady stream of issues complaining about incompatibilities for several years because we weren't correctly handling negative zero. So the change was made, not simply to be standards conformant but also because it was negatively impacting many users in scenarios where knowing the difference between -0 and +0 is "critical".

In particular, this is covered by 5.12 Details of conversion between floating-point data and external character sequences. It is then more specifically covered under 5.12.1 External character sequences representing zeros, infinities, and NaNs:

The conversions (described in 5.4.2) from supported formats to external character sequences and back that
recover the original floating-point representation, shall recover zeros, infinities, and quiet NaNs, as well as
non-zero finite numbers. In particular, signs of zeros and infinities are preserved.

This leaves no room for disambiguation and specifically dictates "the signs of zeros [and infinities] are preserved". As pointed out above, this is also the behavior of other languages such as C/C++, Rust, Java, etc (almost any language that claims IEEE 754 compliance, which is most languages providing some form of floating-point type).

---

As pointed out, you need to be careful when checking certain values. -0 is interpreted by the compiler as the integral 0 where the negative sign is then applied. -0 doesn't have a representation for integers and so it ultimately stays as 0. -0.0 on the other hand is interpreted as a floating-point 0 where the negative sign is then applied. -0.0 does have a representation and is dictated by the spec to become that.

---

double and float being the IEEE 754 types and being binary representations of floating-point values intended for performance and use in all kinds of mathematical scenarios come with many quirks that have to be accounted for. This can range from rounding issues (0.1 + 0.2 != 0.3), to having to deal with +/-0, NaN, and +/-Infinity.

In particular, negative zero exists because rounding exists. It carries stateful information, such that a negative result was rounded to zero due to the constraints of the representation but was not itself zero. This, across multiple operations is important information and impacts the ultimate correctness of various algorithms, including the transcendental functions (sin, cos, tan, etc) or other functions dealing with infinities.

[tannergooding]

I know I can create a custom IFormatProvider or an extension method and convert the double as I want but this requires a change in every conversion in the code and also any developers working on the project will need to use it in the future. In my opionion this solution is not very intuitive and it's likely to be source of errors.

The fix is as you describe, to either create your own extension method/custom format provider that normalizes to +0 or to use a custom-numeric format string.

For example:

public static string ToNormalizedString1(this double value)
{
    if (value == -0.0)
    {
        value = 0.0;
    }
    return value.ToString();
}

public static string ToNormalizedString2(this double value)
{
    return value.ToString("0.####;-0.####;0");
}

The first extension method will check for zero and normalize to positive zero. The second extension method uses the section separator to print positive/negative values with up to 4 fractional digits, if present, and zero as 0 without a sign: https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-numeric-format-strings#the--section-separator

Is there a way to restore the previous behaviour with less effort? Is Microsoft willing to change this in the future versions of the .NET?

Not at this time. CC @jeffhandley

This difference is discussed here https://devblogs.microsoft.com/dotnet/floating-point-parsing-and-formatting-improvements-in-net-core-3-0/ but I don't really agree that this is an improvement as the title states, I believe 0 should not have a sign, it is neither a positive number nor a negative number.

There will always be people that prefer the old behavior and other people that prefer the new behavior. float and double are specifically the IEEE 754 types and follow the requirements laid out by that specification. Us not following that behavior in older versions of .NET (whether full framework or core) was a source of bugs and issues being filed that we weren't doing the correct thing.

Ultimately, the spec defines negative zero to exist and to be formatted as -0.0 by default. This is the behavior you will get in many major languages (C, C++, Rust, Java, etc to name a few) since they also follow the IEEE 754 specification. From a mathematical perspective, it existing also makes sense in various domains and simplifies its usage with using rounded results, dealing with infinities or transcendentals, and other scenarios.

decimal tends to be the type you want if rounding or the existence of negative zero, NaN, or +/-Infinity is problematic.

[tannergooding]

Integers have no way to represent negative zero, Nan, Infinity, or even fractional portions. Every representable value is unique and roundtrips by default.

The same was not true for floating point until it was fixed in .NET Core 3.0.

We don't take breaking changes lightly and do try to have a high compat bar. However, this was a case where the cost of the break vs the cost of the existing behavior were measured and the break ultimately won. There were many factors considered, most of which were listed above.

I would again recommend sing a custom numeric format string or helper function to get the behavior you desire. This is not something we will consider reverting at this time.

[marcocecchiscmgroup]

Integers have no way to represent negative zero,

Indeed! So -1 * 0 = 0 and nobody had bugs in this case? That was my question.

[danmoseley]

@marcocecchiscmgroup we're not planning to change the behavior again due to reasons stated above. We want to make it as easy as possible to move code from .NET Framework to .NET Core. Many customers find no code changes are required but in a few cases they will need code changes due to an intentional breaking change.

Can you say more about the challenge you have using one of the workarounds?

[huoyaoyuan]

Indeed! So -1 * 0 = 0 and nobody had bugs in this case? That was my question.

Integer is integer and floating point is float point. They do not follow the same rules. Integer is a ring with modular arithmetic. There is only overflow, no rounding.

[huoyaoyuan]

I have to point out your mis-expectations. For int or float or double, we are not providing anything specific in .NET. We just expose how numbers are handled by computer hardware for decades.
There is never real methematical numbers in computer. All the numeric types are simulating number in some way and some precision. Even BigInteger is also limited by computer memory. For example in int, there is -2,147,483,648, but no +2,147,483,648. Negating -2,147,483,648 will get itself! And negating 0 will get the same bits. The reason doing so is to help utilization of modular arithmetic. In double there is +0 and -0 with different bits, and they are not always equal. atan2(+0, +0) atan2(+0, -0) atan2(-0, -0) are three different values.

[marcocecchiscmgroup]

we're not planning to change the behavior again due to reasons stated above. We

want to make it as easy as possible to move code from .NET Framework to .NET Core. Many customers find no code changes are required but in a few cases they will need code changes due to an intentional breaking change.

If you're not considering a rollback there's no point in discussing it any further, I am afraid. Anyway, none of what has been said until now is a 'reason', which is what pisses off the most.

Can you say more about the challenge you have using one of the

workarounds? We were aware of the suggested workarounds already, what I am interested here is in preserving the original behaviour. To give you an idea, we are working on a 2M SLOC project, with about 20k unit and integration tests. Most of them are now broken, to be inspected one by one. Il giorno mer 23 giu 2021 alle ore 16:59 Dan Moseley < ***@***.***> ha scritto:

…

@marcocecchiscmgroup <https://github.com/marcocecchiscmgroup> we're not planning to change the behavior again due to reasons stated above. We want to make it as easy as possible to move code from .NET Framework to .NET Core. Many customers find no code changes are required but in a few cases they will need code changes due to an intentional breaking change. Can you say more about the challenge you have using one of the workarounds? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#54537 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUPWTM45UACB3KKWBUUMCD3TUHZFPANCNFSM47DGYLMQ> .

-- HMI ENGINEER RIMINI TECHNOLOGIC UNIT - TECHNICAL DEPARTMENT

--

[stephentoub]

That would be unbelievably noisy, as you suggest, to the point where I don't think it'd be worthwhile in our adding something like that to the SDK. Even if you wanted to do an audit and use such a rule as part of it, I'm not sure it'd yield a meaningfully better experience than just searching for ".ToString()".

[Joe4evr]

@danmoseley CA1305 already exists and ships in-box (tho it's opt-in by having to set the Severity to warn or error).

[stephentoub]

CA1305 already exists and ships in-box

That's about the IFormatProvider. I thought @danmoseley was asking about the format specifier (e.g. "X2")?

[Joe4evr]

D'oh. Yes, that probably would be far to noisy.

[NiclasOlofsson]

@marcocecchiscmgroup if you have most of your 20k unit tests failing because of this, I totally feel your pain. I’m trying to decide if I agree or not, but I have a real hard time understanding your use case where you have 20k unit tests that rely on string comparison of calculated floating point numbers where most of them are rounded to -0.. Would you mind elaborating around the use case this hit for you?

Or are you simply arguing around a principle saying that .NET can not ever introduce breaking changes to fix what Microsoft and the community perceive as bugs?

[marcocecchiscmgroup]

What you could do in case is providing a way to set the default IFormatProvider off-band. Il 24/06/2021 00:23, Dan Moseley ha scritto:

I wonder whether it would help to have an analyzer that flagged calls to |ToString()| on certain types (eg., floating point types, but perhaps all built in numeric types) where there was no format specifier. It would be pretty noisy though. You'd only switch it on to help do a pass, I think. @stephentoub <https://github.com/stephentoub> thoughts about all this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <

#54537 (reply in thread)>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AUPWTMZWOLGB27XGS56IV7DTUJNE5ANCNFSM47DGYLMQ

.

Il giorno gio 24 giu 2021 alle ore 05:59 Stephen Toub < ***@***.***> ha scritto:

…

That would be unbelievably noisy, as you suggest, to the point where I don't think it'd be worthwhile in our adding something like that to the SDK. Even if you wanted to do an audit and use such a rule as part of it, I'm not sure it'd yield a meaningfully better experience than just searching for ".ToString()". — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#54537 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUPWTM3QD4LOH6HDSRAXBUDTUKUSBANCNFSM47DGYLMQ> .

-- HMI ENGINEER RIMINI TECHNOLOGIC UNIT - TECHNICAL DEPARTMENT

--

[marcocecchiscmgroup]

My suggestion was to expose a SetFormatProvider(IFormatProvider) in IFormattable. ToString() always uses the default format provider (which now has changed, i.e. the 'infamous -0.00' one for doubles), but it can be overridden once and for all, in case. IFormattable Il 24/06/2021 15:59, Joe4evr ha scritto:

@danmoseley <https://github.com/danmoseley> CA1305 <

https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1305>

already exists and ships in-box (tho it's opt-in by having to set the Severity to warn or error). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <

#54537 (reply in thread)>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AUPWTM7PJ7GGL2FNTGVBTMLTUM25NANCNFSM47DGYLMQ

.

Il giorno gio 24 giu 2021 alle ore 16:03 Joe4evr ***@***.***> ha scritto:

…

D'oh. Yes, that probably would be far to noisy. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#54537 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUPWTM3XDZM6SPFZWFSBWWLTUM3LVANCNFSM47DGYLMQ> .

-- HMI ENGINEER RIMINI TECHNOLOGIC UNIT - TECHNICAL DEPARTMENT

--

[tannergooding]

Exposing new methods in an interface is a binary breaking change unless they use the newer DIMs feature and provide a default implementation.

There would be no good default implementation that could be provided for this proposed API, the required state to manage it could not be easily implemented by various primitive types. Global overrides are also typically bad due to it allowing a consumer to impact a library in a way that it wasn't tested or setup to handle.

[marcocecchiscmgroup]

I guess you wanted to mention myself. Those uses cases are easily explained as follows. Say we have many computations that end up writing a CNC formalism or an autoCAD dxf, IGES, STEP, etc. We have a whole load of them. The baseline files encode tested situations/fixed behaviours and stuff. They must not be changed, as they represent the core of our business logic. Some date back to long ago, were generated with various software etc. Whenever we run the tests we read some input, re-do the calculations, regenerate the output files and compare them to the baseline. So can you see now? When you come down to numbers, you're messing with all this, it is not just about breaking the compilation. In fact, you all seem to miss this, if you think that this is just a senseless argument. This is not about changing a signature, breaking an interface or so and I have no memory of a compatibility break of such a high reach and impact in any language, but of course my experience might be limited. Otherwise I wouldn't have protested. The fix that I suggested preserves the semantics, has a good design and fits well with the big picture. I see no reason why it should not be considered. Il giorno sab 26 giu 2021 alle ore 01:15 Niclas Olofsson < ***@***.***> ha scritto:

…

@marcelaldecoa <https://github.com/marcelaldecoa> if you have most of your 20k unit tests failing because of this, I totally feel your pain. I’m trying to decide if I agree or not, but I have a real hard time understanding your use case where you have 20k unit tests that rely on string comparison of calculated floating point numbers where most of them are rounded to -0.. Would you mind elaborating around the use case this hit for you? Or are you simply arguing around a principle saying that .NET can not ever introduce breaking changes to fix what Microsoft and the community perceive as bugs? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#54537 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUPWTM5YAVPCOTU5KQOFAVDTUUEXHANCNFSM47DGYLMQ> .

-- HMI ENGINEER RIMINI TECHNOLOGIC UNIT - TECHNICAL DEPARTMENT

--

[tannergooding]

I'm not connecting what is preventing you from updating how you are serializing/formatting/displaying your data to determine equivalence nor why -0.0 in particular is so impactful.

The floating-point formatting/parsing logic had a lot more fixes than just -0.0 but the others don't seem to be impacting you or aren't being raised here. For example, as detailed in the blog post (https://devblogs.microsoft.com/dotnet/floating-point-parsing-and-formatting-improvements-in-net-core-3-0/), Math.PI.ToString() used to return "3.14159265358979" and now returns "3.1415926535897931" because they are fundamentally different values and Math.PI == 3.14159265358979 returns false but Math.PI == 3.1415926535897931 returns true. There are many floating-point values that now return different default strings because the original value did not roundtrip or where parsing a given string now returns a different float because the logic was flawed.

-0.0 is just one facet of many and a format string (either standard or custom) is required to ensure that a given value is displayed correctly.

[marcocecchiscmgroup]

Now that you made me think of it, I think I have found a non workaroundable use case (in the 'your workaround' meaning). Say we use a third-party nuget library to write dxf or whatever files. Of course we cannot fix the ToString() in there. This is unfortunately a show-stopper for everyone, not for us only as we couldn't upgrade and stick with the .NET framework version, that we'll need to ship forever. My suggestion works ok in this respect, btw. Il giorno sab 26 giu 2021 alle ore 15:16 Marco Cecchi < ***@***.***> ha scritto:

…

I guess you wanted to mention myself. Those uses cases are easily explained as follows. Say we have many computations that end up writing a CNC formalism or an autoCAD dxf, IGES, STEP, etc. We have a whole load of them. The baseline files encode tested situations/fixed behaviours and stuff. They must not be changed, as they represent the core of our business logic. Some date back to long ago, were generated with various software etc. Whenever we run the tests we read some input, re-do the calculations, regenerate the output files and compare them to the baseline. So can you see now? When you come down to numbers, you're messing with all this, it is not just about breaking the compilation. In fact, you all seem to miss this, if you think that this is just a senseless argument. This is not about changing a signature, breaking an interface or so and I have no memory of a compatibility break of such a high reach and impact in any language, but of course my experience might be limited. Otherwise I wouldn't have protested. The fix that I suggested preserves the semantics, has a good design and fits well with the big picture. I see no reason why it should not be considered. Il giorno sab 26 giu 2021 alle ore 01:15 Niclas Olofsson < ***@***.***> ha scritto: > @marcelaldecoa <https://github.com/marcelaldecoa> if you have most of > your 20k unit tests failing because of this, I totally feel your pain. I’m > trying to decide if I agree or not, but I have a real hard time > understanding your use case where you have 20k unit tests that rely on > string comparison of calculated floating point numbers where most of them > are rounded to -0.. Would you mind elaborating around the use case this hit > for you? > > Or are you simply arguing around a principle saying that .NET can not > ever introduce breaking changes to fix what Microsoft and the community > perceive as bugs? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#54537 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AUPWTM5YAVPCOTU5KQOFAVDTUUEXHANCNFSM47DGYLMQ> > . > -- HMI ENGINEER RIMINI TECHNOLOGIC UNIT - TECHNICAL DEPARTMENT

-- HMI ENGINEER RIMINI TECHNOLOGIC UNIT - TECHNICAL DEPARTMENT

--

[tannergooding]

This would be an argument for never changing any shipped code ever, which isn't plausible in my opinion.

There are cases, across all of .NET, where fixes, changes, or improvements are needed. We document all of these scenarios and try to increase visibility for bigger changes like the floating-point parsing/formatting fixes: https://docs.microsoft.com/en-us/dotnet/core/compatibility/3.0#floating-point-formatting-and-parsing-behavior-changed.

Downstream libraries, especially those related to display, formatting, or serialization, realistically need to expose additional overloads to allow customization so consumers can customize that as needed for their given scenario.

[marcocecchiscmgroup]

The floating-point formatting/parsing logic had a lot more fixes than just

-0.0 but the others don't seem to be impacting you or aren't being raised here.

For example, as detailed in the blog post (

https://devblogs.microsoft.com/dotnet/floating-point-parsing-and-formatting-improvements-in-net-core-3-0/), Math.PI.ToString() used to return "3.14159265358979" and now returns "3.1415926535897931" because they are fundamentally different values How many "patriot’s bug" have you been reported over your career? The reason for what you describe is quite clear to me, nonetheless what I reported are facts and I am afraid you will experience how impacting is this over time.

There would be no good default implementation that could be provided for

this proposed API,

Global overrides are also typically bad

I don't understand to what extent a functional, unworkaroundable break you can fly over, while an interface change is something you can’t get away with. I guess this is somewhat aside from your own former ‘apology of breaks’. Anyway the default implementation would be what's currently defaulted in the latest version. So, I think we need to move on and deal with this, one way or another, as it we’ve got a definite answer already. This is becoming like playing the Don Quixote, which I don’t want to. Il giorno sab 26 giu 2021 alle ore 16:46 Tanner Gooding < ***@***.***> ha scritto:

…

Exposing new methods in an interface is a binary breaking change unless they use the newer DIMs feature and provide a default implementation. There would be no good default implementation that could be provided for this proposed API, the required state to manage it could not be easily implemented by various primitive types. Global overrides are also typically bad due to it allowing a consumer to impact a library in a way that it wasn't tested or setup to handle. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#54537 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUPWTMZ5ALGRBSS7BWQYCNTTUXR5XANCNFSM47DGYLMQ> .

-- HMI ENGINEER RIMINI TECHNOLOGIC UNIT - TECHNICAL DEPARTMENT

--

[tannergooding]

I don't understand to what extent a functional, unworkaroundable break you can fly over, while an interface change is something you can’t get away with.

There are different kinds of breaks and they all have different impacts. We generally categorize them as:

• Functionality Breaking
• Source Breaking
• Binary Breaking

A functionality breaking change is generally the least impactful and is the most common. We make no changes to the public surface area and instead just change the internal implementation to do the new/correct thing. Such changes work with existing compiled code and new compiled code and so it will be automatically picked up by anything running on the new binaries. Changes such as the floating-point parsing/formatting one here and most other bug fixes fall into this category. The biggest drawback with these kinds of changes is that it can break users depending on the prior functionality and the discussion here tends to focus solely on whether or not such a break is appropriate and what users can or cannot do to get the old behavior.

A source breaking change is one where some detail of the public surface area changes in a compatible manner and it will break users upon recompilation. That is, already compiled code continues working, but newly compiled code may behave differently or even fail to compile. This is generally measured as "worse" than a functionality breaking change as it can make previously valid code no longer compile or can introduce hard to diagnose issues because compiling with two different versions of the SDK and running in the same setup can cause different behavior.

A binary breaking change is one where some detail of the public surface changes in an incompatible manner. It forces users to recompile and any existing compiled binaries are now considered invalid. This is generally measured as the worst kind of breaking change and is what removing a type or method or adding a new abstract method to a class/interface would fall under. These kind of changes basically reset the ecosystem, particularly if they happen in the core libraries.

You can have changes that cross multiple categories and there are cases where one kind is preferred over another (such as preferring a source-break over a functionality break). For every break, there are generally many facets considered and the route that is considered to have the most positive and least negative impact is generally taken. The positives and negatives are sometimes viewed differently by different people and that must also be taken into account. That is, a change may be viewed negatively by a person who it negatively impacts but positively by a developer who it positively impacts, and so we often have to consider things like:

• What would we have done if we were designing this with all of the available knowledge from day 1?
• What are other languages/ecosystems doing?
• What is the industry standard here?
• What code is this going to impact?
• What workarounds are available?
• What areas are workarounds going to be unavailable?
• etc

Several of these consideration facets can have greater impact than others, particularly where there are additional considerations or requirements for it to be true and they may vary from scenario to scenario. For example, roundtripping has more impact when interchange is concerned but often less impact when simply displaying data in a user interface.

[Larry57]

Go explain that to an end user...

ToString() is used to present a value, with a formatting option.

Except for scientists, computer enthusiasts and other respectable mathematicians, a user does not want to see -0.0 when a value is zero, and forgive me, they don't give a damn about the IEEExxxx standard.

I totally respect this point of view, but ToString() has been around long enough that it should be allowed to do what it was designed to do: format a number for a user for as many use cases as possible.

If we now have to be subtle because of the IEEE standard, we should instead have proposed a specific formatter, and not touch the default behavior, even if that disconcerts a minority of purists.

There you go, that was my two cents. I'm going to have to review my entire UI. THANK YOU.

[tannergooding]

Using ToString to generate a value for display is only one part of the picture. Another and far more important factor is that ToString needs to correctly pair with Parse for the purposes of serializing and therefore allowing a value to correctly roundtrip.

The pros, cons, user expectations, existing defaults in other languages, and overall trend of behavior for such types in other ecosystems were all considered and the best choice for .NET was determined to be to take the behavioral change, to fix the known bugs/problematic cases in this area, and to ensure that values would always roundtrip by default.

Users who are wanting to display these values, such as in UI, have many options to ensure the values are normalized if that’s appropriate for their scenario and where they likely want to be normalizing them already to account for other edge cases that existed prior to the behavioral break discussed in this issue.

[Larry57]

I agree with all your points, except the last one:
That the default behavior of ToString() has changed, certainly, the decision is debatable, I have to accept it and I ended up accepting it because of the necessary alignment with other languages.
However, no formatter is provided to restore the same behavior as before, so you have to juggle with a horrible if (value == 0.0) { value = 0.0; ... } or abominable .Replace() instructions.
Even if I have to pepper my code with directives to avoid this “-”, I'd like to find a clean solution.

[marcocecchiscmgroup]

If this requirement is apparently so strict, according to what you say, so why "roundtripping" didn't work before and everyone was happy with that?

Never break user-space [cit]

[tannergooding]

Everyone was not happy with the prior behavior.

As was indicated elsewhere in this issue we had literally over a decade worth of feedback and bugs from users making the exact opposite complaint of the one you’re making. They specifically were unhappy that ToString was lossy, that -0 did not display, etc.

.NET Framework has a much higher backwards compatibility bar, so much so that we continue to preserve some known bugs like this to this day.

.NET Core, due to its deployment model, represented an opportunity to start fixing such things and that was an explicit goal around the modernization of .NET.

The blog post that discusses this break and other threads, such as this issue, discuss multiple workarounds and the tradeoffs between them. They indicate what the prior behavior was generally equivalent to (G15), what behavior is not preserved, how things like custom numeric format strings do have a more stringent back compat view and can be used to help handle cases like -0, etc.

We understand this is a pain point for some users and it makes the porting process to modern .NET more difficult, but it is ultimately one of many cases where the bug fix was the best thing for the entire ecosystem of millions of .NET Developers. Where the significant number of developers who have ported to .NET Core over the nearly past 10 years have seen massive overall improvements in performance, stability, maintainability and more