> Floats (doubles) can accurately represent all integers up to 2⁵³, so there > is no inaccuracy in this range; the result from round() or floor() could > therefore be safely passed to (int) even if the cast operator checked for a > 0 fractional part, which is what I'm advocating for.
Generating a warning on explicit casts of (non-integer) floats to int would IMO make no sense at all, it would put PHP at odds with other major languages such as C, Python and Java and go against normal, reasonable expectations of how a programming language behaves. You said in an earlier comment "it's better to be explicit about your intent", but doing something like (int)3.5 *is* being explicit about your intent - and truncating casts on float to int is the widely established norm. This was exactly my reservation about deprecating this behaviour even as an implicit cast - in my mind it isn't a bug or flaw, it's there by design. If developers want to round/ceil/floor/do whatever with a float prior to using it as an int, they already have that option and the greatest flexibility. At least with the implicit case, I understand the motivation and argument for bringing coercion more in line with strict typing behaviour and catching cases where such a cast may not have been intentional (though I still think a warning is too high an error level for this and would favour a notice or deprecation, were it to be done at all). On Fri, Feb 5, 2021 at 12:52 PM Benjamin Morel <benjamin.mo...@gmail.com> wrote: > On Fri, 5 Feb 2021 at 11:56, AllenJB <al...@allenjb.me.uk> wrote: > > > (And after checking the manual, I'd also note here that round() also > > returns a float, so how exactly does your example here work? Is it only > > OK to explictly cast a float that's the return value of a function? Or > > only explictly cast a float if the fractional part is .0? Is that viable > > given the "inaccuracy" of floats? Or would it be better for PHP to have > > some non-range/accuracy-sensitive representation for integers (and > > decimals) here?) (and now we're getting into "why are we still using > > floating point math by default in 2021" territory, so I'll stop right > here) > > > > Floats (doubles) can accurately represent all integers up to 2⁵³, so there > is no inaccuracy in this range; the result from round() or floor() could > therefore be safely passed to (int) even if the cast operator checked for a > 0 fractional part, which is what I'm advocating for. > > There are legitimate cases for explicitly casting floats to int. For > > example floor() outputs a float, but in the context of the domain I'm > > working I might know that the result is never going to exceed a certain > > value and want the result explicitly as an int. > > > Perfect, so (int) floor() would work wonders for you, even with the strict > casting I'm talking about. > And if the result does overflow an integer one day, I'm sure you'd be happy > to know it by getting an exception, rather than getting silently ZERO: > > echo (int) 1e60; // 0 > > — Benjamin >
