On Sun, Mar 10, 2024, at 10:31 AM, Gina P. Banyard wrote: > On Saturday, 9 March 2024 at 16:00, Larry Garfield > <la...@garfieldtech.com> wrote: > >> I am still opposed to this. Logically, ceil/float/round should be returning >> ints, not floats. Only returning ints if it was given an int is, er, kinda >> pointless, as you'll just get back the value you passed in. (Because it's >> already rounded/floored, etc.) So this doesn't get us any new type safety, >> but does make the return type less consistent than it is today. That's a >> step backwards. >> >> If there's some math reason that we cannot have those functions return int >> (someone mentioned there was, but I don't really understand it and the RFC >> does not explain it at all), then we should at least keep consistency in the >> return type. "Sometimes I have to cast the return value before I can >> actually use it in the obvious way, sometimes I don't" is not a good >> situation. >> >> --Larry Garfield > > There are plenty of values that are exactly representable as floating > point numbers but not as integers. > > One short example: > > $v = 1e10 + 0.6; > var_dump($v); > var_dump(round($v)); > > Gives you accurate precision and proper rounding behaviour. > > 1e10 *cannot* be represented as an integer. > > So round *must* be able to return a float. > > Best regards, > > Gina P. Banyard
Please include some version of this in the RFC. Especially if it can be even more detailed. --Larry Garfield
