On Thu, 4 Feb 2021 at 17:55, Benjamin Morel <benjamin.mo...@gmail.com> wrote:
> On Thu, 4 Feb 2021 at 17:05, G. P. B. <george.bany...@gmail.com> 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 <davidgeb...@gmail.com> wrote: > On Thu, Feb 4, 2021 at 7:22 PM Larry Garfield <la...@garfieldtech.com> > 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 the value received, etc.). Considering what my long term goal is with this proposal I think I will change this to a deprecation and write an annexe document which I can refer to. The feedback so far has thus been productive. Best regards, George P. Banyard
