Fix Decimal for Swift 5.2

Since Swift 5.2 seems to be considered a "…significant quality and performance enhancements" release, can we PLEASE fix Decimals in Swift?

https://bugs.swift.org/browse/SR-920

and also the blatant data corruption when using Codable:

https://bugs.swift.org/browse/SR-7054?jql=text%20~%20"decimal%20codable"

Sry for whining here but it really boggles my mind how this can go unsolved for so long.

5 Likes

Decimal isn't part of swift. It's a part of Foundation, a closed-source apple framework that is older than the swift project, so "us fixing Decimals in Swift" isn't possible, apple has to fix it themselves.

There's also swift-corelibs-foundation that's open source, but just tries to maintain feature parity with apple foundation

1 Like

But the problem that Decimal can't be initialized exactly from what looks like a decimal literal, but is actually a floating point literal, is definitely a part of Swift. Apple couldn’t fix this in Foundation without also introducing proper decimal literals to Swift.

“We” can certainly fix this; the way to do so is outlined in the bug. I’d like to see it fixed as well but I don’t have time to do it.

I’m not sure what we’re discussing here. Are you volunteering to implement the redesign?

2 Likes

Sadly my skills aren't nearly sufficient in that regard, so we're discussing "Please can someone fix this" rather :slight_smile:

It's unfortunate that it's been this way for so long, but I don't think these forums are really the place for "this is broke and I really want it fixed now" topics.

There are many things in the Swift toolchain and compiler that are frustrating to work with, either because they don't exist (generic math functions, a standard library BigNum/BigDecimal, first-class concurrency, local lazy/property wrappers, etc), or they don't work quite right (this being a good example, or most of the linux foundation, SPM still missing key features)

I think the best thing to do in these cases is to comment on the bug tracking this issue and to try and get it prioritized.

The forums would be a good place to ask for help in the implementation of the changes, or if there are still outstanding design questions, we can discuss those. But just saying, "hey, this should be fixed in Swift 5.2", isn't going to be very productive. As I think we all can think of several things we would like to see fixed in Swift ASAP.

5 Likes

Adding to what @nuclearace said: "this is important to me" is a useful signal to have in the bug tracker. "This is important to me because I need to do ..." is even better, and has the additional benefit that in many cases someone will be able to provide you with a workaround or alternative solution in the meantime.

3 Likes

I apologise if I came across too demanding or complaining, and while I can sympathise with your points of view, I think that it does not quite apply.

This is not only something that "is important to me" but something that is fundamentally broken in the language for quite some time imho.

I know that I am in no position to argue about that, if only it was for my inferior knowledge of numerics, but if a common user can't initialise a decimal variable without immediately getting a corrupt value, that's seriously broken, and not a matter of "just for me, or some users".

I have filed many bugs, and happily continue to do so, but this one doesn't get the attention it deserves I think, and commenting on the bug reports has done nothing it seems to me.

3 Likes

Of course, this is a nasty gotcha that has been sitting around in the language since forever. And maybe it was a mistake to have Decimal conform to the float literal protocol without this "bug" fixed, but we can't really change that now. Just today I was toying around with creating a BigDecimal type built on AttaSwift's BigInt and I remembered this exact pitfall WRT float literals. Which is why I'm not making my BigDecimal type conform to that literal protocol.

Perhaps a more interesting discussion is to look at why it hasn't been fixed in all these years. Is the solution truly a difficult one to implement? Is the suggested solution even still viable? If it isn't viable, what are the alternatives? We could maybe even start looking for some pointers on where someone should start playing around with trying to tackle the issue.

1 Like
Terms of Service

Privacy Policy

Cookie Policy