Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123724
Precedence: bulk
MIME-Version: 1.0
References: <CAPzBOBMidokE3xw251f+_qbCPAyQQRcN1WnyVF0xfuzaPBU3JA@mail.gmail.com>
 <9d28c9tOCChpWUcP1SFiFwtf2-w2XAtDzHsmM73myA7zfBsn7TxxEqs-VCnxRAgZjsk2TxS55owmM8wSLgBQL8LgeQLntUQ9toeLMkjTVx4=@gpb.moe>
 <673a1803-83c4-44b4-bd73-4ba61e83412e@app.fastmail.com> <350c1531-9bcf-4e7c-824b-8d9904b9e48e@rwec.co.uk>
In-Reply-To: <350c1531-9bcf-4e7c-824b-8d9904b9e48e@rwec.co.uk>
Date: Fri, 21 Jun 2024 14:27:34 +0200
Message-ID: <CAPzBOBMw=Hn4SabAq0FeppLpQMwRJh2Ffc3JhhFFOps85XNazw@mail.gmail.com>
Subject: Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Fri, Jun 21, 2024 at 12:54=E2=80=AFAM Rowan Tommins [IMSoP]
<imsop.php@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=3D1);
> 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 intend=
ed for - HTTP is a text-based protocol, so most PHP applications are dealin=
g with string input and output *all the time*.
>
> One of the things the language badly needs, and I have been trying to com=
e up with a proposal for, is strict type casts, so that this code can actua=
lly 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" =3D> 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