Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128978
Precedence: list
MIME-Version: 1.0
References: <CAMU7irLdQg3UVT-SLmyCLWm4Qp81jAcU5uw3Jt=qBpaJCCWWpg@mail.gmail.com>
 <E98C3CE4-3959-4376-A37B-E94E142B3ED6@rwec.co.uk> <CAMU7irLBUAU2t4Den6M8kpPD6wHppM=HphRgjbaiz8j-ZO93OQ@mail.gmail.com>
 <f6d9f646-cc4c-48d6-9017-b7f4966dcab2@rwec.co.uk>
In-Reply-To: <f6d9f646-cc4c-48d6-9017-b7f4966dcab2@rwec.co.uk>
Date: Mon, 27 Oct 2025 12:20:53 -0300
Message-ID: <CAPbW5OOg2gYe9z9Gnb_BthRS3XT_Gu1EZD4L64m3GXyOfttnLg@mail.gmail.com>
Subject: [PHP-DEV] [RFC] Nullable and non-nullable cast operators
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000c1b9330642257263"
From: hwapx.dev@gmail.com (HwapX)

--000000000000c1b9330642257263
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 27, 2025, 09:55 Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk>
wrote:

> Hi Alexandre,
>
> On 27/10/2025 08:03, Alexandre Daubois wrote:
>
> Thank you for your interest! I get your concerns about the extension
> of such syntax, but we don't feel that there would be a particular
> need of extending this syntax. The syntax does not bring something
> really new: the behavior described in the RFC already exists in PHP =E2=
=80=94
> we are just making it available at the cast level with explicit null
> handling.
>
>
> I definitely agree that reusing the behaviour from the existing scalar
> parameter/return checks makes a lot of sense. I also agree that allowing
> nullable types as the target of the cast is a useful feature.
>
> What I'm not convinced by is that those two features should be combined
> into one:
>
> $foo =3D '123abc';
>
Why not create a separate RFC to deprecate and remove(9.0) this and others
strange cast behaviors.

Then after it finishes decide how to processed with this one?

There no need to rush, php 8.6 will be released only next year

--000000000000c1b9330642257263
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote gmail_quote_container"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Mon, Oct 27, 2025, 09:55 Rowan Tommin=
s [IMSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">imsop.php@rwec.co.uk<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

 =20
   =20
 =20
  <div>
    <div>Hi Alexandre,</div>
    <div><br>
    </div>
    <div>On 27/10/2025 08:03, Alexandre Daubois
      wrote:<span style=3D"white-space:pre-wrap">
</span></div>
    <blockquote type=3D"cite">
      <pre>Thank you for your interest! I get your concerns about the exten=
sion
of such syntax, but we don&#39;t feel that there would be a particular
need of extending this syntax. The syntax does not bring something
really new: the behavior described in the RFC already exists in PHP =E2=80=
=94
we are just making it available at the cast level with explicit null
handling.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>I definitely agree that reusing the behaviour from the existing
      scalar parameter/return checks makes a lot of sense. I also agree
      that allowing nullable types as the target of the cast is a useful
      feature.=C2=A0</p>
    <p>What I&#39;m not convinced by is that those two features should be
      combined into one:</p>
    <p>$foo =3D &#39;123abc&#39;;<br></p></div></blockquote></div></div><di=
v dir=3D"auto"><div dir=3D"auto">Why not create a separate RFC to deprecate=
 and remove(9.0) this and others strange cast behaviors.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Then after it finishes decide how to proce=
ssed with this one?=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">There no need to rush, php 8.6 will be released only next year</div></div=
></div>

--000000000000c1b9330642257263--