I think the README should document at least two more features in the code:

• the fact that the package has builtin support for github.com/google/go-cmp, making comparisons reliable and reasonably fast without having to resort to Amount.Cmp when just testing for equality
• the implementation of the encoding.BinaryMarshaler interface actually produces valid strings in its []byte results, allowing them to be stored in database as strings in SQL and compared for equality, but not for ordering.

Alternatively, documenting a serialization that would allow SQL ordering would be nice too. I didn't find one in the current implementation, though.

Bug description

decimalContext function returns globals which shouldn't be modified concurrently. Amount.RoundTo modifies the returned context's Rounding property which causes data race condition when Amount.RoundTo is called concurrently anywhere.

My proposition

Copy the context just in Amount.RoundTo method to make it safe for concurrent writes. In all other methods where the decimalContext is used it can be left as-is since no write operations are performed there.

I considered also an option with not using globals at all and returning a copy every time from the decimalContext func, but I'll leave it up to you to decide if this optimization is needed.

Enable handling of 64-bit integer and big integer amount values in minor units. These types are seen in financial and banking APIs to avoid the possibility of invalid amounts when dealing with multiple currencies that have varying decimal handling.

Related to #5 (implementation can be done separately with these changes in place)

Benchmarks show ericlagergren/decimal to be noticeably faster than cockroachdb/apd, along with doing less allocations. We should try switching.

I'd like to get an answer to https://github.com/ericlagergren/decimal/issues/153 before I merge this, since the current checks feel a bit repetitive.

EDIT: Answer received, waiting on maintainer fix.

Financial systems and APIs use minor amounts in order to make it impossible to encounter invalid amounts, like '0.5 JPY' or '0.001 EUR' that aren't allowed per ISO-4177 currency standard.

Embedded the Amount type, to keep all calculation handling logic in the same place. For conversion to string (Number method and encoding) the minor unit string is used instead of the locale-encoded string.

Fixes #5

First of all, thank you for the great library. It helped my team with printing currencies a lot! 🎖️

Regarding the PR: When fetching ISO data, let's not skip currencies basing on arbitrary picked terms, but instead skip only when they're missing required properties.

We've noticed that issue when one of our clients started using CHE currency and we weren't able to format it with your library. Turned out it was skipped due to IsFund flag, while it had all the required properties to get included.

These are all skipped currencies now:

2022/03/25 14:15:21 Fetching ISO data...
Skipping 'No universal currency' (country: ANTARCTICA) - it has no code defined.
Skipping 'XDR' - it has no digits defined.
Skipping 'XUA' - it has no digits defined.
Skipping 'No universal currency' (country: PALESTINE, STATE OF) - it has no code defined.
Skipping 'XSU' - it has no digits defined.
Skipping 'No universal currency' (country: SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS) - it has no code defined.
Skipping 'XBA' - it has no digits defined.
Skipping 'XBB' - it has no digits defined.
Skipping 'XBC' - it has no digits defined.
Skipping 'XBD' - it has no digits defined.
Skipping 'XTS' - it has no digits defined.
Skipping 'XXX' - it has no digits defined.
Skipping 'XAU' - it has no digits defined.
Skipping 'XPD' - it has no digits defined.
Skipping 'XPT' - it has no digits defined.
Skipping 'XAG' - it has no digits defined.

Hi! Thanks a bunch for this very useful package.

Consider summing a slice of amounts. The natural code to write is something like:

func Sum(amounts []currency.Amount) (currency.Amount, error) {
	var sum currency.Amount
	for _, x := range amounts {
		var err error
		sum, err = sum.Add(x)
		if err != nil {
			return currency.Amount{}, err
		}
	}
	return sum, nil
}

However, this code doesn't work, because sum gets initialized to the zero value, which has an empty currency code. Playground: https://go.dev/play/p/SzMyDcxcos7

I propose that Add and Sub the zero value (0 number, empty currency code) as special, and ignore currency mismatches in this case, adopting the non-empty currency code.

I also hit something similar in currency.Amount.Scan. I want to be able to store the zero value in the database, as a "not yet initialized, unknown currency" value. But loading such a value from the database using currency.Amount.Scan fails, because the empty currency code is not valid. I similarly propose that Scan have a special case for number = 0 and currency code consisting of all spaces ("" or " "), and allow it to be parsed without error.

Thanks again.

Are there any plans to support storing Amount in no-sql databases? (for example mongo)

If not do you have any tips on how to store that info? (mostly the number part concerns me)

if using CAD currency for example, and i want to display the symbol for "en-CA", GetSymbol prioritizes "en" over "en-CA" so it will return "CAD$" and not "$"

Problem discovered in https://github.com/bojanz/currency/pull/7, the RoundTo() tests are taken from there.

~~Still needs additional test coverage (in tests other than the one for RoundTo).~~

Went with a simpler/more performant way of selecting the precision, what do you think @Kunde21?

Financial APIs use minor values in order to avoid any invalid amounts or ambiguous encoding.

As this library stands, it is unable to handle parsing amounts from or writing amounts to a string in minor units. ToMinorUnits risks overflow attacks on int64 datatype.

I am using PQ driver panics at this line as the type of src is []unit8

https://github.com/bojanz/currency/blob/28b0298f7e60bd74027682fe75cbea971893442a/amount.go#L347

maybe should check for types. something like the following

https://github.com/rengas/currency/blob/253a204a22fbe171270075154ea9076769c8b87c/amount.go#L349