IMO this is a bugfix and should then be based on the 2.7 branch.

and even if we decide to consider it as a feature, it should go in 3.4, not in master (which is currently 4.0)

We should try harder to fix the issue for everyone without resorting to bcmath: the function_exists() check means some ppl will have the correct behavior, and some others will have the bug. This wouldn't qualify as a correct bugfix to me.

@nicolas-grekas polyfill for bcmath? ;) Not that trivial I assume.

@Tobion I think bcmath-polyfill wouldn't be out of the question. I have seen stuff like adding/multiplying large numbers as code kata before. I think it's more of a question of whether the trade off precision vs. performance is worth it? After all, if I know this issue I can avoid it in other ways in my application which better suit my needs. For example I could be doing (int)(string) $value which is fine in my code where I know that using the divisor will only return floats that should represent a full int value (and where I can probably add comments as to why this weird construct is there), but probably not in Symfony?

edit: But I would certainly be interested in seeing a more generic solution to this. I'm interested to see what @nicolas-grekas or someone else can come up with. 🙂

I think we can work around the issue by enforcing a precision of 14, which is way enough for a money transformer, and is the minimal precision to represent most float accurately (the max is 17, but we don't care for the potential precision loss at this scale in this specific case).

When working with money/currency and precision is required, the usage of strings and proper libraries should be enforced. The usage of floats/doubles and simply using * and / can lead to extremely annoying bugs as shown in the example.

See #21769 for a similar issue that we solved using cast-to-string.
We should do the same here IMHO.

@nicolas-grekas thank you for digging down through the older PRs.
As I understand the older PR that you mentioned, a solution could be to cast the whole operation to string? The return type of reverseTransform and transform would change from int|float to string.

/**
* Transforms a localized money string into a normalized format.
*
* @uses extension bcmath
*
* @param string $value Localized money string
*
* @return string Normalized number
*
* @throws TransformationFailedException If the given value is not a string
*                                       or if the value can not be transformed.
*/
public function reverseTransform($value)
    {
        $value = parent::reverseTransform($value);
        if (null !== $value) {
            $value = (string) ($value * $this->divisor);
        }
        return $value;
    }

/**
* Transforms a localized money string into a normalized format.
*
* @requires extension bcmath
*
* @param string $value Localized money string
*
* @return string Normalized number
*
* @throws TransformationFailedException If the given value is not a string
*                                       or if the value can not be transformed.
*/
public function transform($value)
    {
        if (null !== $value) {
            if (!is_numeric($value)) {
                throw new TransformationFailedException('Expected a numeric.');
            }
            $value = (string) ($value / $this->divisor);
        }
        return parent::transform($value);
    }

I mean we could do it the other way around and cast the string from my solution to float to stick to the return type:

$value = (float) function_exists('bcmul') ? bcmul((string) $value, (string) $this->divisor, $this->scale) : $value * $this->divisor;
/* ... */
$value = (float) function_exists('bcdiv') ? bcdiv((string) $value, (string) $this->divisor, $this->scale) : $value / $this->divisor;

But this looks a bit weird in my opinion ^^. What do you prefer?

public function reverseTransform($value)
{
    $value = parent::reverseTransform($value);

    if (null !== $value) {
        $value = (string) ($value * $this->divisor);

        if (ctype_digit($value)) {
            $value = (int) $value;
        } else {
            $value = (float) $value;
        }
    }

    return $value;
}

What about something like this?

@smoench. Thank you for that hint. I removed it.

Could this be merged?

Some background: We know floats cannot be represented perfectly so there is some lost precision.
So a float like 36.55 * 100 can actually be 3654.99999999.
The problem when you cast that float to int, PHP cuts the scale and that leaves you with an 3654 instead of 6355. By string casting, PHP will use the number precision and realize 3654.99999999 is just meant to be 3655 and then casting that to float again the float will be represented as something like 3655.00000001 instead which will also cast to the expected integer again.

I wondered how many common montary values are affected by this difference and if it's reliable. Or if there are numbers where the string cast approach actually doesn't work as expected as well. I wrote a little script: https://3v4l.org/JdfjZ

For numbers between 1 and 99999.
Unexpected count traditional approach: 4586
Unexpected count new approach: 0

That makes me wonder by PHP by default does not do this automatically, i.e. (int) $float === (int) (string) $float. I guess that would solve some unexpected floating precision with type casting either explicitly or implicitly by scalar type declarations.

Thank you @Rubinum.

I've found out the behavior also depends on the precision ini setting.

When setting ini_set('precision', 17); or when using the new ini_set('precision', -1); from https://wiki.php.net/rfc/precise_float_value, there is no unexpected behavior.
So for master with php 7.1., we could remove these workarounds and add recommendation to our requirements to use ini_set('precision', -1) which seems much better in most cases. That is the new PHP default anyway, but some users might not make use of it and use old ini values. For example https://3v4l.org does not use the new ini even for PHP >= 7.1 by default.

Actually, this change is not reliable at all what I was fearing the whole time. It only works because the precision is only 14. But if you increase the precision or use PHP 7.1 with more precision by default, (float) (string) $float does not change anything at all. See https://3v4l.org/La5iR

We could for precision to 14 if we want to provide robustness for this (here and in #21769)
(or we an assume nobody changes this "precision" setting and ensure this in check.php)
@Tobion would you do one of the 2 PRs?

Neither of that is a proper solution. The only one is using fixed precision calculation with bcmath.

Then bcmath for ppl having it and precision 14 for others? I don't think we can add a strong requirement for bcmath, do you?

Using bcmath and precision as fallback seems fine to not break BC. But IMO we should add requirement for bcmath in Symfony 4 so we can remove that ugly workaround. Bcmath is included by default in php so that shouldn't cause much trouble.

It's included really? Cool, so we can trigger a deprecation on 3.4 and throw on 4.0.

There is another problem, Im doing a cents to decimal, using MoneyType, so I setted the divisor to 100, but when persisinting an entity, it puts the decimals, like 100.0, thats a problem, when you have the same value, like the entity has 100 and then it tries to update to 100.0 (what is the same thing), but it triggers an useless update that hits the database.

@arthurlauck apply the appropriate casting in your entity setter then

@stof I ended up, extending the MoneyType, would it be better to cast in the entity?

public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder->addViewTransformer(new CallbackTransformer(fn($value) => $value, fn($value) => (int) $value));

        parent::buildForm($builder, $options);
    }