[9.x] Fix decimal cast, again

[timacdonald]

For 9.x, alternative to: #45580
For 10.x, Supersedes: #45457

This implementation handles both rounding and arbitrary sized floats, restoring the rounding functionality while addressing the large float issue.

It supports systems with bcmath or gmp, and delegates to pure PHP implementations when these are not found, meaning that it does not introduce any hard extension requirements to the framework.

This PR introduces brick/math in order to handle the rounding.

Some points to consider on introducing a new framework dependency...

Adding to the dependency tree

brick/math is already a sub-dependency of laravel/framework via ramsey/uuid. brick/math only requires the JSON extension and has no sub-dependencies.

Package is pre-1.0

From the readme:

While this library is still under development, it is well tested and considered stable enough to use in production environments.

This package is already used in brick/money, which is an extremely popular money handing library, second to moneyphp/money.

Used for only one method

Introducing an entire dependency for a single method feels like a lot, however this library could be used to improve other parts of the framework.

• The multiple_of rule could potentially drop it's dependency on the bcmath extension.
• Addition improvements I've mentioned in our internal Slack.

Nice to have

I believe it is nice to have a strong math library in the framework anyway. Requiring it directly may lead others to the package and learn to improve their own handling of large numbers within their own applications.

[barryvdh]

Yeah I think this is a lot cleaner, while not breaking BC :)

I understand the dependency concern, but if it's already loaded anyways.. Only thing I might consider is handling the exception differently, eg catch the bigmath exception and throw a Laravel exception. In that case you keep the implementation of bigmath internal, in case you need to swap it out later (or bigmath changes it).

[timacdonald]

Good thinking. I have wrapped brick/math exceptions in a first party exception.

This does not meant it is not breaking if the underlying exception changes, as the "previous" exception will have changed and code may rely on its state, but at least it can continue to be caught via try / catch.

I've placed the exception in Illuminate\Support as the framework will need the exception in other parts of the framework, not just Illuminate\Database. Illuminate\Database required Illuminate\Support already.

[timacdonald]

Thanks for the feedback and help on this @barryvdh