Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123714
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------Ur3Bhj5bKToxOOshV8tyHBc1"
Message-ID: <350c1531-9bcf-4e7c-824b-8d9904b9e48e@rwec.co.uk>
Date: Thu, 20 Jun 2024 22:39:11 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"
To: internals@lists.php.net
References: <CAPzBOBMidokE3xw251f+_qbCPAyQQRcN1WnyVF0xfuzaPBU3JA@mail.gmail.com>
 <9d28c9tOCChpWUcP1SFiFwtf2-w2XAtDzHsmM73myA7zfBsn7TxxEqs-VCnxRAgZjsk2TxS55owmM8wSLgBQL8LgeQLntUQ9toeLMkjTVx4=@gpb.moe>
 <673a1803-83c4-44b4-bd73-4ba61e83412e@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <673a1803-83c4-44b4-bd73-4ba61e83412e@app.fastmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------Ur3Bhj5bKToxOOshV8tyHBc1
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------Ur3Bhj5bKToxOOshV8tyHBc1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 19/06/2024 16:34, Larry Garfield
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:673a1803-83c4-44b4-bd73-4ba61e83412e@app.fastmail.com">
      <pre>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.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Used correctly, it absolutely does. Used incorrectly, it can
      actually end up *hiding* errors.</p>
    <p>I've seen lots of cases where code like this:</p>
    <p>some_function_expecting_int($_GET['foo']);</p>
    <p>Gets changed to this:</p>
    <p>declare(strict_types=1);<br>
      some_function_expecting_int( (int)$_GET['foo'] );</p>
    <p>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 "".<br>
    </p>
    <p>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*.<br>
    </p>
    <p>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.<br>
    </p>
    <p><br>
    </p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------Ur3Bhj5bKToxOOshV8tyHBc1--