Fix #295 | String Trim Trailing Zeros bool variable

[vasilbekk]

Fix #295

[mcdee]

Also see #281 which provides this plus additional functionality.

[davseby]

Also see #281 which provides this plus additional functionality.

This is different as by globally setting the trim trailing zero bool value you don't need to handle the JSON MarshalText or MarshalJSON methods for structures. The Format method would still require you to do so.

[vasilbekk]

Also see #281 which provides this plus additional functionality.

This is different as by globally setting the trim trailing zero bool value you don't need to handle the JSON MarshalText or MarshalJSON methods for structures. The Format method would still require you to do so.

Absolutely! Thank you for your attention and answer, it's really pleasant.

[mwoss]

I apologize for the late review. Seems like a great addition to library, thanks!

[mwoss]

I think we can simply call it TrimTrailingZeros, trimming is an action widely used on strings in various languages. Or do you think it could be a bit misleading as NewFromString or RequiredFromString would not perform trimming?

[mwoss]

I also wonder whether we should introduce another config var for specifying NewFromString behaviour. The current implementation does not trim zeroes during the initialization from string, but we saw in the past that some developers would like to see such an option.
Unfortunately, we cannot use this newly introduced variable for both of these cases as we would break backward compatibility.

[mwoss]

Could we separate test cases for TrimTrailingZeros=true and TrimTrailingZeros=false? Thanks to that we could easily catch potential bugs and it would improve overall code maintainability.

[mwoss]

Suggested change

	// StringTrimTrailingZeros should be set to false if you want the decimal stringify without zeros trailing.
	// By default, when decimal is output as a string (for example, in JSON), zeros are truncated from it (2.00 -> 2, 3.11 -> 3.11, 13.000 -> 13).
	// But this logic can be changed by this variable.
	// For example, if you have numeric(10,2) values stored in your database,
	// and you want your API response to always be given 2 decimal places (even 2.00, 3.00, 17.00 [not 2,3,17]),
	// then this variable is a great way out.
	// TrimTrailingZeros specifies whether trailing zeroes should be trimmed from a string representation of decimal.
	// If set to true, trailing zeroes will be truncated (2.00 -> 2, 3.11 -> 3.11, 13.000 -> 13),
	// otherwise trailing zeroes will be preserved (2.00 -> 2.00, 3.11 -> 3.11, 13.000 -> 13.000).
	// Setting this value to false can be useful for APIs where exact decimal string representation matters.

[mwoss]

What do you think about it? A bit simplified and a bit more explicit version of your suggestion.

[shuqingzai]

Hope this PR will be completed soon.

[JohnAD]

@mwoss @vasilbekk Is there upcoming progress on this? It is a road-blocker for me. A library I'm writing reads a JSON doc with Decimal marshaling. So if it reads

{ "foo": 12.300 }

and I make no changes to the doc and write it back out again, is it writing

{ "foo": 12.3 }

For my library, which does git-tracking of JSON, this is a serious problem.

If this has stalled, let me know. I'm happy to clone this branch and make an appended PR with the changes you have suggested.

While I'm at it I could also add a Match method that both compares the "scalar" value (like Equal does) as well as the exponent. So, (psuedo-code) "12.3".Equals("12.30") but !"12.3".Match("12.30").

In the meantime I'm using the greatcloak fork. But that one has a dependency on the entire MongoDB driver. That is too much overhead for my project.