On Fri, Jun 21, 2024 at 12:54 AM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote: > > On 19/06/2024 16:34, Larry Garfield wrote: > > Also, as someone who does put every file into strict mode as a matter of > course, and appreciates the many languages that do not even have a > concept of non-strict mode (like Go or Rust), I really don't appreciate > the backhanded comments in this thread about people who, you know, care > about type safety. (Something that weak mode, when it was introduced in > PHP 7, only marginally provided if at all.) Strict mode prevents bugs, > full stop, and we should not fault anyone for applying that bug-stopper > tool liberally. > > > Used correctly, it absolutely does. Used incorrectly, it can actually end up > *hiding* errors. > > I've seen lots of cases where code like this: > > some_function_expecting_int($_GET['foo']); > > Gets changed to this: > > declare(strict_types=1); > some_function_expecting_int( (int)$_GET['foo'] ); > > Even in PHP 7.0, the first version is actually *stricter* than the second, > because explicit casts never fail, but parameter coercion (mode 0) always > failed for strings like "hello"; as of 8.0, it also fails for strings like > "123foo" and "". > > And this is exactly the kind of code that coercive type hints were intended > for - HTTP is a text-based protocol, so most PHP applications are dealing > with string input and output *all the time*. > > One of the things the language badly needs, and I have been trying to come up > with a proposal for, is strict type casts, so that this code can actually be > written safely but still concisely.
This is why I wanted to work on "as" part of the pattern matching. It isn't clear what will happen with the actual pattern matching RFC (yet), but being able to do: some_function_expecting_int($_GET['foo'] as ?int); would be super nice. I think it just depends on if we wanted to go the C# route (where "as" => null if not an int/null) or throw an error if it isn't one of those types. The more I think about it, I kinda like the C# way, but I feel like the error way is more idiomatic for PHP, which is much stricter on nullables. > HTTP is a text-based protocol, so most PHP applications are dealing with > string input and output *all the time*. In PHP, pretty much everything starts as a string because everything starts as a series of bytes, which can only be represented as a string in PHP. There's always something that has to convert those bytes into more useful information (whether that string is human-readable or not). Sometimes, a PHP extension will do it for you, and sometimes, it won't, and you have to do it yourself. Doing it yourself is usually where you don't want strict types (if you trust coercion to behave as documented) or want more control, so you turn on strict types. There's quite a lot of footguns with strict types (like the one you mentioned), but also others, particularly in library code that accepts callbacks. Robert Landers Software Engineer Utrecht NL
