Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
This is all a bit moot anyway, the RFC proposal is for warnings or notices
on implicit casts only.
I'm not a voting member for RFCs so my opinion is mere food for thought,
nonetheless my two cents is that:
a) The proposal relies on a premise that an implicit cast of (non-zero
fractional) float to int is inherently ambiguous or a mistake.
I disagree with this as outlined in my previous messages; namely my
objection is truncating a float on cast to int is the widely established
normal behaviour in numerous programming languages.
There should not be a penalty in the form of an error just for doing such a
conversion implicitly, in accordance with how PHP's type coercion works by
design.
b) String offsets, where a warning occurs already, is something of a
special case; this warning was added I believe (5.4?) because malformed
string offset was a known common error in the community. It's not even
entirely consistent; $foo["2"] is fine, $foo[2.5] is a warning with offset
[2], $foo["2x"] is a warning with offset [2] and $foo["2.5"] is a TypeError.
c) It's a substantial BC breaking change likely to affect a lot of existing
code, even though that code works as intended.
d) If it is implemented at all, it should not be an error level as high as
a warning.
-Dave
On Sat, Feb 6, 2021 at 7:32 PM Rowan Tommins
wrote:
> On 06/02/2021 14:47, Christian Schneider wrote:
> > I'm sure there is a lot of code which takes user input and uses (int)
> casts to ensure they are dealing with integers.
> > There is also intval() as an alternative but my guess would be that real
> world code uses 50% (int) and 50% intval() to do this.
>
>
> My thoughts exactly. Code along these lines is common and, in my
> opinion, perfectly reasonable:
>
> $id = (int)$_GET['id'];
> if ( $id !== 0 ) {
> // throw an exception, return false, look up a default, etc, as
> the application's design requires
> }
> // proceed knowing that $id is a non-zero integer
>
>
> I would however welcome a new function or syntax that either performs a
> "strict cast" (producing an error if the cast is lossy in any way) or
> checks in advance if a cast *would be* lossy.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
On 06/02/2021 14:47, Christian Schneider wrote:
I'm sure there is a lot of code which takes user input and uses (int) casts to
ensure they are dealing with integers.
There is also intval() as an alternative but my guess would be that real world
code uses 50% (int) and 50% intval() to do this.
My thoughts exactly. Code along these lines is common and, in my
opinion, perfectly reasonable:
$id = (int)$_GET['id'];
if ( $id !== 0 ) {
// throw an exception, return false, look up a default, etc, as
the application's design requires
}
// proceed knowing that $id is a non-zero integer
I would however welcome a new function or syntax that either performs a
"strict cast" (producing an error if the cast is lossy in any way) or
checks in advance if a cast *would be* lossy.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
Am 06.02.2021 um 01:17 schrieb Benjamin Morel : > Could we at least fix the odd cases where the cast is definitely a failure? > Like: > > (int) 1e60; // 0 > (int) "foo"; // 0 Are you talking about the constant values 1e60 and "foo"? If not then please don't add a warning (or worse). I'm sure there is a lot of code which takes user input and uses (int) casts to ensure they are dealing with integers. There is also intval() as an alternative but my guess would be that real world code uses 50% (int) and 50% intval() to do this. This would be a big BC break IMHO. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
On 5 February 2021 23:45:59 GMT, David Gebler wrote: >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. I'd just like to point out that a deprecation notice implies (or should imply!) that the behaviour will be completely removed in a future version. So it doesn't really make sense to say "a warning is too much, but I'm fine with it being an error in the future". Probably, E_DEPRECATED shouldn't be considered its own severity level, but an extra flag paired with either E_WARNING or E_NOTICE. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
On Fri, Feb 5, 2021 at 6:46 PM David Gebler 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 > wrote: > > > On Fri, 5 Feb 2021 at 11:56, AllenJB 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
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
On Sat, 6 Feb 2021 at 00:46, David Gebler wrote: > 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). > Let's agree to disagree on what would be the ideal behaviour of type casts. I do understand that it would be a big concern for BC if (int) stopped working for floats with a fractional part. Could we at least fix the odd cases where the cast is definitely a failure? Like: (int) 1e60; // 0 (int) "foo"; // 0 — Benjamin
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
> 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 wrote: > On Fri, 5 Feb 2021 at 11:56, AllenJB 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 >
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
On Fri, 5 Feb 2021 at 11:56, AllenJB 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
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
On 04/02/2021 17:54, Benjamin Morel wrote: On Thu, 4 Feb 2021 at 17:05, G. P. B. wrote: Greetings internal, I'm proposing a new RFC which would warn when an implicit conversion from float to int occurs. The draft is currently located on GitHub: https://github.com/Girgias/float-int-warning/ for ease of commenting/providing changes to it. The official discussion phase wouldn't start before I convert it to docwiki and post it on the wiki, something I'm planning to do next week. Any feedback is appreciated. Best regards, George P. Banyard Hi George, Thank you for this proposal, I'm all for it, though I'd go one step further, and actually issue a warning during explicit casting as well: (int) 3.5; // E_WARNING (int) round(3.5); // OK In my experience, it's better to be explicit about your intent, so forcing the user to round() before casting when the float has a fractional part is OK to me. This would help prevent weird silent conversions such as when you cast to (int) from user input: $age = $_GET['age']; // '25.75' $x = (int) $foo; // I'd expect a warning, not a silent conversion to 25 — Benjamin 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. (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) AllenJB PS. Apologies for the dupe to those who did receive my original send, but I forgot to amend my from address to my subscribed address and as I recall the list doesn't like list-only replies) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
On Thu, 4 Feb 2021 at 17:55, Benjamin Morel
wrote:
> On Thu, 4 Feb 2021 at 17:05, G. P. B. wrote:
>
>> Greetings internal,
>>
>> I'm proposing a new RFC which would warn when an implicit conversion
>> from float to int occurs.
>>
>> The draft is currently located on GitHub:
>> https://github.com/Girgias/float-int-warning/
>> for ease of commenting/providing changes to it.
>>
>> The official discussion phase wouldn't start before I convert it to
>> docwiki
>> and
>> post it on the wiki, something I'm planning to do next week.
>>
>> Any feedback is appreciated.
>>
>> Best regards,
>>
>> George P. Banyard
>>
>
> Hi George,
>
> Thank you for this proposal, I'm all for it, though I'd go one step
> further, and actually issue a warning during explicit casting as well:
>
> (int) 3.5; // E_WARNING
> (int) round(3.5); // OK
>
> In my experience, it's better to be explicit about your intent, so forcing
> the user to round() before casting when the float has a fractional part is
> OK to me.
> This would help prevent weird silent conversions such as when you cast to
> (int) from user input:
>
> $age = $_GET['age']; // '25.75'
> $x = (int) $foo; // I'd expect a warning, not a silent conversion to 25
>
> — Benjamin
>
As Rowan said explicit casts are already very fuzzy and should be handled
globally, although I don't agree that they should be changed.
An explicit cast is a choice to *force* the value to a given type, and many
cases are somewhat reasonable
(e.g. (array) 5 giving array(1) { [0]=> int(5) }), there are IMHO only two
types of blatant bogus type casts which are array being casted to string,
and array/objects being casted to int/float.
And by the looks of it these casts were added *because* of the usage of the
strict_type declare, which encourages the usage of explicit cast despite
them leading to *less* type safe code.
This proposal is one of the stepping stones needed to make the strict_type
declare obsolete by converging the behaviour of the coercive typing mode to
the strict type one.
The more I think about it, the more I think it's just a bandaid on some of
the suboptimal behaviour PHP traditionally had.
However, many of these have been somewhat fixed in PHP 8, the two major
ones are systematic TypeErrors for internal functions and the other one is
a saner definition of what a numeric string is.
There are currently 3 remaining reasons, at least from my
perspective/knowledge, as to why the strict_type mode is still needed in
PHP 8:
- Internal functions being implicitly nullable, something being
deprecated with Nikita's RFC [1] which is currently passing with flying
colours.
- Implicit float to int conversions, which this RFC is trying to address
- Implicit boolean to scalar conversions, something I want to look into
afterwards but it has a larger surface area which needs to be considered
All other implicit conversions, which currently do not warn or error, are
reasonable from my PoV, and if a codebase wants to adhere to strict type
safety rules there are enough different static analysers nowadays to
achieve this, as strict_types does *not* achieve this but provides a false
sense that it does.
On Thu, 4 Feb 2021 at 19:43, David Gebler wrote:
> On Thu, Feb 4, 2021 at 7:22 PM Larry Garfield
> wrote:
> > On Thu, Feb 4, 2021, at 12:06 PM, David Gebler wrote:
> > > 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.
>
> 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.
>
If you don't care that it has a factional part, then yes it is unambiguous
(which is kind of debatable with the fact floating numbers can be slightly
below the integer value which it should represent when operations have been
done to them).
However, if you don't care then an explicit cast is totally in order to
signal this, as IMHO most people want to have some sort of indication that
they are receiving a float instead of an integer as that can mean there is
an issue prior to receiving it,
as it may need some further processing (be that rounding, increasing
validation on t
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
> 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 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 > >
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
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
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
On 04/02/2021 17:54, Benjamin Morel wrote: $age = $_GET['age']; // '25.75' $x = (int) $foo; // I'd expect a warning, not a silent conversion to 25 If we want to make explicit casts "fussy", that would be a much bigger change. Right now, the following are all valid, with no warnings, even though they are all lossy conversions: (int)25.75, (int)"25.75", (int)"hello", (int)"99 red balloons", (bool)2, (bool)"yes", (float)"3.1415 is not pi", (string)M_PI, // calling this "lossy" is a bit of a stretch, but it will retain decimal rather than binary precision There's a case to be made for "strict casts" - I've pointed out before that so-called "strict types" mode encourages users to write code that is actually *less* strict, because explicit casts are very forgiving. However, they should probably be a new syntax, because there will be an ENORMOUS amount of code using deliberately using the existing casts in lossy situations. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
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. So in these cases, via coercion you're just straightforwardly giving a valid, unambiguous integer to something which expects an integer. I'd question why should that raise a warning or TypeError. In favour of the proposal are a couple of the other issues you mentioned which mean this would make PHP a bit more consistent all-round...but I'm not entirely persuaded at this point. -Dave On Thu, Feb 4, 2021 at 4:05 PM G. P. B. wrote: > Greetings internal, > > I'm proposing a new RFC which would warn when an implicit conversion > from float to int occurs. > > The draft is currently located on GitHub: > https://github.com/Girgias/float-int-warning/ > for ease of commenting/providing changes to it. > > The official discussion phase wouldn't start before I convert it to docwiki > and > post it on the wiki, something I'm planning to do next week. > > Any feedback is appreciated. > > Best regards, > > George P. Banyard >
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
On Thu, 4 Feb 2021 at 17:05, G. P. B. wrote: > Greetings internal, > > I'm proposing a new RFC which would warn when an implicit conversion > from float to int occurs. > > The draft is currently located on GitHub: > https://github.com/Girgias/float-int-warning/ > for ease of commenting/providing changes to it. > > The official discussion phase wouldn't start before I convert it to docwiki > and > post it on the wiki, something I'm planning to do next week. > > Any feedback is appreciated. > > Best regards, > > George P. Banyard > Hi George, Thank you for this proposal, I'm all for it, though I'd go one step further, and actually issue a warning during explicit casting as well: (int) 3.5; // E_WARNING (int) round(3.5); // OK In my experience, it's better to be explicit about your intent, so forcing the user to round() before casting when the float has a fractional part is OK to me. This would help prevent weird silent conversions such as when you cast to (int) from user input: $age = $_GET['age']; // '25.75' $x = (int) $foo; // I'd expect a warning, not a silent conversion to 25 — Benjamin
[PHP-DEV] [RFC] Warning for implicit float to int conversions
Greetings internal, I'm proposing a new RFC which would warn when an implicit conversion from float to int occurs. The draft is currently located on GitHub: https://github.com/Girgias/float-int-warning/ for ease of commenting/providing changes to it. The official discussion phase wouldn't start before I convert it to docwiki and post it on the wiki, something I'm planning to do next week. Any feedback is appreciated. Best regards, George P. Banyard
