On Fri, Feb 5, 2021 at 6:46 PM David Gebler <davidgeb...@gmail.com> wrote:
> > 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). > > A notice is fine, but PLEASE don't make it a warning. I'm in the process of upgrading to 8.0 right now and I have so much code that works perfectly fine but generates warnings (undefined array key for example - in 99.9% of the cases where an array key is not defined, the null value that used to result from that was perfectly fine). > > 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 > > > -- Chase Peeler chasepee...@gmail.com
