> Except that example is ambiguous.  Specifically, which is more logical,
to truncate it to 3 or round it up to 4?  It probably depends heavily on
your context.  Implicitly doing one or the other can result in surprises.

I disagree this is ambiguous. The integral portion of a float is what it
is, any notion of rounding it up is no more relevant here than multiplying
by it 20, calculating it's sin value or anything else you can do with a
number. These are operations you explicitly choose to perform on a scalar.

On Thu, Feb 4, 2021 at 7:22 PM Larry Garfield <la...@garfieldtech.com>
wrote:

> On Thu, Feb 4, 2021, at 12:06 PM, David Gebler wrote:
> > If this were to be done, my gut feeling is a notice would be preferable
> to
> > a warning, particularly as there must be many scripts which would
> suddenly
> > start churning out warnings for this proposed change which might/probably
> > ignore lower error levels and emitting a warning for a previously common
> > script behaviour is quite a significant backwards incompatible change.
> >
> > The bit which makes me more nervous about the proposed change is your
> > rationale that implicit float to int conversion dropping the fractional
> > portion means there is "no way to know if the data provided is
> erroneous".
> >
> > I get the idea behind your proposal, but equally I'm not convinced this
> is
> > comparable to numeric vs non-numeric or malformed/partially numeric
> > strings. There isn't any value of the string "foobar" which makes sense
> as
> > an integer. But there is a value for a float which makes sense as an
> > integer; the integral part. In the float 3.81232 the integral portion 3
> is
> > completely unambiguous. It's not like it would make just as much sense to
> > interpret it as any other arbitrary integer value.
>
> Except that example is ambiguous.  Specifically, which is more logical, to
> truncate it to 3 or round it up to 4?  It probably depends heavily on your
> context.  Implicitly doing one or the other can result in surprises.
>
>
> My main concern is if you're casting floats to ints and the floats are
> usually ints anyway, and so no error, you may not even realize the error
> remains for a long time until you suddenly start getting a warning if your
> incoming data shifts.  I have no idea how common that pattern is in
> practice, though.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Reply via email to