On Thu, 5 Oct 2023 at 07:40, Marc Bennewitz <marc@mabe.berlin> wrote:
> I don't see a bug or broken behavior here as these functions were > processing floating point numbers since .... forever. > > https://3v4l.org/PrrmO > That's not my point, the point is about the function being broken for large 64bit integers, which your RFC is fixing. I would also expect most people that actually use ceil/floor/round to dump the return value of it into a property/value that is expected to be an int. Which is also compatible for floats that fit in an int (and since 8.2 for those that have a fractional part a warning is emitted). I see no benefit in doing this weird approach instead of just changing the behaviour. Yes this is a theoretical BC break [1], but unless you can show me an actual use case that breaks (and even then) I don't think the approach of this RFC is good. Best regards, George P. Banyard [1] And this is coming from me, who does love finding weird edge cases and remove them from the language, just look at the 8.3 range() RFC
