[11.x] Add precision support to Number::currency()

[xHeaven]

Number::format() has this functionality.
Number::percentage() also has this functionality.
fileSize, abbreviate, forHumans, summarize also has this functionality.

It makes no sense not to add this option for the currency method.

There are times when you don't want to force your application to spit out currencies with 2 decimals - sometimes you want to work with either more or less. This PR does just that.

We've had this issue in our project, where we needed to format a bunch of numbers, percentages and currencies - however, only the first two could be done with precision, so we had to reinvent the wheel, and make our own currency helper.

Consistency is key, if every method can use precision, the currency method should also be able to have this feature. Let us do it the Laravel way, don't force us to make dumb workarounds.

[xHeaven]

Just a sidenote: probably the best would be being able to pass a $formatterCallback to every method, so that people could provide a custom formatter for their numbers - with sensible defaults, of course.
This just came to my mind, because, for example, if someone wants to use traditional rounding (aka half-up) instead of banker's rounding (default ICU), they'd still have to rely on a third party implementation.
Also, this feature would cause fewer headaches in the future, in case people ask for more and more options. They could just pass their own formatting as a callback.

[shaedrich]

fyi: We had a discussion in #54163 about currency-specific precision that might interest you

[xHeaven]

fyi: We had a discussion in #54163 about currency-specific precision that might interest you

Yeah, I'm aware. There were also multiple PRs, like this and this, that got closed, but we need to have some kind of control over currencies, at least with the precision if not the rounding itself*. I want to be able to change WHAT is being shown to the user, if I can't change HOW it's shown.

*this part is already quite problematic anyway as the default banker's rounding is not always a good idea

[selcukcukur]

It's necessary to prefer using more secure packages for these processes. Yes, the helper class provides a basic method, but you still definitely need a package for financial transactions. Therefore, I think it is unnecessary.

[xHeaven]

It's necessary to prefer using more secure packages for these processes. Yes, the helper class provides a basic method, but you still definitely need a package for financial transactions. Therefore, I think it is unnecessary.

With this argument in mind, the currency() method could be removed altogether. However, if you know that it doesn't suit every use case and you are still willing to use it, at least have some option to configure what it looks like - just like every other method in the Number class, which suffers from the exact same rounding issues.

[taylorotwell]

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If applicable, please consider releasing your code as a package so that the community can still take advantage of your contributions!

[xHeaven]

Welp, workaround it is, then.