Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129935
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------ZBT0axIv4pahDALN80wdjGEj"
Message-ID: <85c420f7-38ba-46f6-b434-addb733d023d@rwec.co.uk>
Date: Mon, 26 Jan 2026 18:41:04 +0000
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Deprecate Fuzzy Type Casts and Allow Stringable
 in Strict Mode
To: internals@lists.php.net
References: <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
 <CANS-=pfCasTNSAMSdL8ajJMnrwNpfvbEOoQTQhAQ=X73iG+_tw@mail.gmail.com>
 <CAMU7irLgsMCzHsQDD6Ok2zJZsNyV7LF-PHotzqvSGRAkN9bovg@mail.gmail.com>
 <31563ed1-ac44-47ef-9fca-3ebbfc567ba5@sandfox.me>
 <CAMU7irLSn2KhhyFotxaqBTS6MYiHmEZH69gAELXrmRRvKHZLqA@mail.gmail.com>
 <8A9F3BDD-1C65-4E6F-BD65-C43F017D52E2@rwec.co.uk>
 <CAMU7ir+JvXsEM4CM_VthUKXi_8G4W+6b+Z7BBTuQRCHbgM7Qzw@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAMU7ir+JvXsEM4CM_VthUKXi_8G4W+6b+Z7BBTuQRCHbgM7Qzw@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------ZBT0axIv4pahDALN80wdjGEj
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 26/01/2026 08:46, Alexandre Daubois wrote:
> Le ven. 23 janv. 2026 à 18:46, Rowan Tommins [IMSoP]
> <imsop.php@rwec.co.uk> a écrit :
>> I don't think we should repurpose widely-used syntax for a different use case. If we want new functionality, with new semantics, we should add new syntax for that.
> The rules/semantics proposed in this RFC are not new.


Hi Alexandre,

In my mind, cast / type conversion behaviour can be described in two parts:


The first part is the rules of which input values count as "valid".

In the case of string to integer casts: can it include a leading '+'? 
leading space? trailing space? leading zeroes? trailing zero decimal 
part? trailing non-zero decimal part? other trailing characters?

PHP has a bunch of different versions of these rules used in different 
contexts, and it would certainly be nice to make them all more consistent.


The second part is the behaviour of what happens for a value which is 
*not* valid.

In the case of parameter types and return types, this is to throw a 
TypeError. But that's not the only reasonable option - you might just a 
boolean (true=valid, false=invalid); or you might want to substitute a 
default value.

In the case of the "(int)" syntax, I would argue that the established 
behaviour is that an invalid value *returns a default value* - for an 
integer, zero.

In other words, I don't think (int)'hello' is a "fuzzy cast", it is an 
operator with clear and useful behaviour: reject 'hello' as input for 
integer, and substitute default zero.


The "(int)" syntax has had that behaviour in PHP for over 20 years, and 
a huge amount of code has been written explicitly making use of that 
fact. For instance, I see this pattern a lot:

$foo = (int)$_GET['foo'];
if ( $foo !== 0 ) { ... }

Changing the behaviour of (int) so that it throws a TypeError for 
invalid cases would be a hugely disruptive change, and would replace one 
useful feature with a different useful feature, rather than having good 
syntax for both.


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------ZBT0axIv4pahDALN80wdjGEj
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 26/01/2026 08:46, Alexandre Daubois
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMU7ir+JvXsEM4CM_VthUKXi_8G4W+6b+Z7BBTuQRCHbgM7Qzw@mail.gmail.com">
      <pre class="moz-quote-pre" wrap=""><pre wrap=""
      class="moz-quote-pre">Le ven. 23 janv. 2026 à 18:46, Rowan Tommins [IMSoP]
<a class="moz-txt-link-rfc2396E" href="mailto:imsop.php@rwec.co.uk"
      moz-do-not-send="true">&lt;imsop.php@rwec.co.uk&gt;</a> a écrit :
</pre><blockquote type="cite" style="color: #007cff;"><pre wrap=""
      class="moz-quote-pre">I don't think we should repurpose widely-used syntax for a different use case. If we want new functionality, with new semantics, we should add new syntax for that.
</pre></blockquote><pre wrap="" class="moz-quote-pre">The rules/semantics proposed in this RFC are not new. </pre></pre>
    </blockquote>
    <p><br>
    </p>
    <p>Hi Alexandre,</p>
    <p>In my mind, cast / type conversion behaviour can be described in
      two parts:</p>
    <p><br>
    </p>
    <p>The first part is the rules of which input values count as
      "valid". </p>
    <p>In the case of string to integer casts: can it include a leading
      '+'? leading space? trailing space? leading zeroes? trailing zero
      decimal part? trailing non-zero decimal part? other trailing
      characters?</p>
    <p>PHP has a bunch of different versions of these rules used in
      different contexts, and it would certainly be nice to make them
      all more consistent.</p>
    <p><br>
    </p>
    <p>The second part is the behaviour of what happens for a value
      which is *not* valid.</p>
    <p>In the case of parameter types and return types, this is to throw
      a TypeError. But that's not the only reasonable option - you might
      just a boolean (true=valid, false=invalid); or you might want to
      substitute a default value.</p>
    <p>In the case of the "(int)" syntax, I would argue that the
      established behaviour is that an invalid value *returns a default
      value* - for an integer, zero. </p>
    <p>In other words, I don't think (int)'hello' is a "fuzzy cast", it
      is an operator with clear and useful behaviour: reject 'hello' as
      input for integer, and substitute default zero.</p>
    <p><br>
    </p>
    <p>The "(int)" syntax has had that behaviour in PHP for over 20
      years, and a huge amount of code has been written explicitly
      making use of that fact. For instance, I see this pattern a lot:</p>
    <p>$foo = (int)$_GET['foo'];<br>
      if ( $foo !== 0 ) { ... }</p>
    <p>Changing the behaviour of (int) so that it throws a TypeError for
      invalid cases would be a hugely disruptive change, and would
      replace one useful feature with a different useful feature, rather
      than having good syntax for both.</p>
    <p><br>
    </p>
    <p>Regards,</p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------ZBT0axIv4pahDALN80wdjGEj--