Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129735
Content-Type: multipart/alternative;
 boundary="------------lmpB9JxmeJV7tHRxKKXrp2LA"
Message-ID: <b13af656-0139-4d57-8bc3-650184390174@gmail.com>
Date: Tue, 6 Jan 2026 01:56:50 +0700
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Nullable and non-nullable cast operators
To: Alexandre Daubois <alex.daubois+php@gmail.com>,
 PHP internals list <internals@lists.php.net>
References: <CAMU7irLdQg3UVT-SLmyCLWm4Qp81jAcU5uw3Jt=qBpaJCCWWpg@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAMU7irLdQg3UVT-SLmyCLWm4Qp81jAcU5uw3Jt=qBpaJCCWWpg@mail.gmail.com>
From: vadim.dvorovenko@gmail.com (Vadim Dvorovenko)

This is a multi-part message in MIME format.
--------------lmpB9JxmeJV7tHRxKKXrp2LA
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

> Nicolas Grekas and I would like to propose this new RFC to the
> discussion. This proposes to introduce two new cast operators to the
> language: `(?type)` and `(!type)`.
>
> Please find the details here:
> https://wiki.php.net/rfc/nullable-not-nullable-cast-operator

Hi, Alexandre.
I was just starting to think about writing such RFC, and you already did 
it )) As for me, now is good time to return to idea of such operators. I 
really needed it some days ago ))

The idea is not new, here is https://wiki.php.net/rfc/nullable-casting 
previous simular RFC, but you did not refer it in your RFC. Please list 
it in you references.

Previous RFC described settype function behavior changes. Please 
describe it (as well as not changing, if you prefer).

But your RFC brings two ideas, of (?type) and (!type) operator. I think, 
it's not good idea to discuss and bring them together.

(?type)

  * the idea came up a long time ago and by several independent people
    (see previous rfc).
  * "spelling" of the type corresponds to the "spelling" of the types of
    parameters and results of functions and class properties
  * such operator is just syntax sugar and could be transpiled to simple
    ternary operator (if php was js ))) )
  * discussion about that operator could be same level as about ?? or
    ??= operators

(!type)

  * This is a relatively new idea
  * the "spelling" can be interpreted ambiguously, ! is widely used as
    boolean NOT, and currently in php never as strictness. Here can be
    separate discussion about best symbol to such semantics
  * it correlates with strict_types option, can throw new error type and
    can not be considered syntax sugar
  * there can be much more discussion about exception type to throw (see
    Larry's Garfield message)
  * to reduce cohesion with strict_types directive, we may introduce as
    new declare(strict_casts=1) directive. That's subject of discussion too

May be it would be better to separate RFC for two different features. It 
will simplify discussions.

--------------lmpB9JxmeJV7tHRxKKXrp2LA
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>
    <blockquote type="cite"
cite="mid:CAMU7irLdQg3UVT-SLmyCLWm4Qp81jAcU5uw3Jt=qBpaJCCWWpg@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">Nicolas Grekas and I would like to propose this new RFC to the
discussion. This proposes to introduce two new cast operators to the
language: `(?type)` and `(!type)`.

Please find the details here:
<a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/nullable-not-nullable-cast-operator">https://wiki.php.net/rfc/nullable-not-nullable-cast-operator</a></pre>
    </blockquote>
    <p>Hi, Alexandre.<br>
      I was just starting to think about writing such RFC, and you
      already did it )) As for me, now is good time to return to idea of
      such operators. I really needed it some days ago ))</p>
    <p></p>
    <p>The idea is not new, here is
      <a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/nullable-casting">https://wiki.php.net/rfc/nullable-casting</a> previous simular RFC,
      but you did not refer it in your RFC. Please list it in you
      references.</p>
    <p>Previous RFC described settype function behavior changes. Please
      describe it (as well as not changing, if you prefer).</p>
    <p>But your RFC brings two ideas, of (?type) and (!type) operator. I
      think, it's not good idea to discuss and bring them together.</p>
    <p>(?type)</p>
    <ul>
      <li>the idea came up a long time ago and by several independent
        people (see previous rfc).</li>
      <li>"spelling" of the type corresponds to the "spelling" of the
        types of parameters and results of functions and class
        properties</li>
      <li>such operator is just syntax sugar and could be transpiled to
        simple ternary operator (if php was js ))) )</li>
      <li>discussion about that operator could be same level as about ??
        or ??= operators</li>
    </ul>
    <p>(!type)</p>
    <ul>
      <li>This is a relatively new idea</li>
      <li>the "spelling" can be interpreted ambiguously<span
        class="Y2IQFc" lang="en" style="white-space: pre-wrap;">, ! is widely used as boolean NOT, and currently in php never as strictness. Here can be separate discussion about best symbol to such semantics</span></li>
      <li><span class="Y2IQFc" lang="en" style="white-space: pre-wrap;">it correlates with strict_types option, can throw new error type and can not be considered </span>syntax
        sugar<span class="Y2IQFc" lang="en"
        style="white-space: pre-wrap;"></span></li>
      <li><span class="Y2IQFc" lang="en" style="white-space: pre-wrap;">there can be much more discussion about exception type to throw (see Larry's Garfield message)</span></li>
      <li>to reduce cohesion with strict_types directive, we may
        introduce as new declare(strict_casts=1) directive. That's
        subject of discussion too</li>
    </ul>
    <p>May be it would be better to separate RFC for two different
      features. It will simplify discussions.</p>
  </body>
</html>

--------------lmpB9JxmeJV7tHRxKKXrp2LA--