Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127542
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------5gTV5N99HR0T5UBciazQVLjR"
Message-ID: <7f7dc3dc-bb9a-4f6e-9b77-055c4a8801d1@rwec.co.uk>
Date: Mon, 2 Jun 2025 21:50:42 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Transform void into an alias for null
Content-Language: en-GB
To: internals@lists.php.net
References: <6Z2Ysh6MjYp1nyzuB0bTPJc5srObIcMRqt731JaQeXUJk1f_V_Yo2nRn8WvjI7er7pp7pIUE6WYl5pRwvYrtcrd07nCutyAqKPSsZHmrS-Y=@gpb.moe>
In-Reply-To: <6Z2Ysh6MjYp1nyzuB0bTPJc5srObIcMRqt731JaQeXUJk1f_V_Yo2nRn8WvjI7er7pp7pIUE6WYl5pRwvYrtcrd07nCutyAqKPSsZHmrS-Y=@gpb.moe>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------5gTV5N99HR0T5UBciazQVLjR
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 02/06/2025 17:27, Gina P. Banyard wrote:
> The objective is to fix a weird quirk of PHP's type system, where void lives in its own type hierarchy.
> This is visible mainly in that a lack of return type is not isomorphic to a function that has a return type of mixed.


I think if "void" was added now, it would be an attribute, rather than a 
type. It is in effect the exact opposite of #[\NoDiscard], and 
distinguishes between these two cases:

interface Foo {
    public function getSomething(): ?Something;
}

class MyFoo implements Foo {
    public function getSomething(): null {
        // My result is always null, but still meaningful to consumers 
of the Foo interface
        return null;
    }

    #[\DiscardReturn]
    public function doSomething(): null {
         // I have no meaningful information to return; any assignment 
of my implicit value is a mistake
    }
}

I agree the type hierarchy you describe is weird, but rather than 
throwing away the functionality completely, I wonder if we can make it 
more consistent:

- Make "no return type declared" and "mixed" equivalent
- Make "void" a sub-type of "null", and therefore a sub-type of "mixed"

If I've got that right, this would then be legal:

class A{ public function foo() {} } class B extends A{ public function foo(): mixed{} }
class C extends B{ public function foo(): null{} }
class D extends C{ public function foo(): void{} }
class E extends D{ public function foo(): never {} }

That seems reasonable enough; I may have missed something important, though.

Regards,

-- 
Rowan Tommins
[IMSoP]

--------------5gTV5N99HR0T5UBciazQVLjR
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 02/06/2025 17:27, Gina P. Banyard
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:6Z2Ysh6MjYp1nyzuB0bTPJc5srObIcMRqt731JaQeXUJk1f_V_Yo2nRn8WvjI7er7pp7pIUE6WYl5pRwvYrtcrd07nCutyAqKPSsZHmrS-Y=@gpb.moe">
      <pre class="moz-quote-pre" wrap="">The objective is to fix a weird quirk of PHP's type system, where void lives in its own type hierarchy.
This is visible mainly in that a lack of return type is not isomorphic to a function that has a return type of mixed.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>I think if "void" was added now, it would be an attribute, rather
      than a type. It is in effect the exact opposite of #[\NoDiscard],
      and distinguishes between these two cases:</p>
    <p>interface Foo {<br>
         public function getSomething(): ?Something;<br>
      }</p>
    <p>class MyFoo implements Foo {<br>
         public function getSomething(): null {<br>
             // My result is always null, but still meaningful to
      consumers of the Foo interface<br>
             return null;<br>
         }<br>
    </p>
    <p>   #[\DiscardReturn]<br>
         public function doSomething(): null {<br>
              // I have no meaningful information to return; any
      assignment of my implicit value is a mistake<br>
         }<br>
      }</p>
    <p>I agree the type hierarchy you describe is weird, but rather than
      throwing away the functionality completely, I wonder if we can
      make it more consistent:</p>
    <p>- Make "no return type declared" and "mixed" equivalent<br>
      - Make "void" a sub-type of "null", and therefore a sub-type of
      "mixed"</p>
    <p>If I've got that right, this would then be legal:</p>
    <pre class="code php"><span class="kw2">class</span> A <span
    class="br0">{ </span><span class="kw2">public</span> <span
    class="kw2">function</span> foo<span class="br0">(</span><span
    class="br0">)</span> <span class="br0">{</span><span class="br0">}</span> <span
    class="br0">}
</span><span class="kw2">class</span> B extends A <span class="br0">{ </span><span
    class="kw2">public</span> <span class="kw2">function</span> foo<span
    class="br0">(</span><span class="br0">)</span>: mixed <span
    class="br0">{</span><span class="br0">}</span> <span class="br0">}</span>
<span class="kw2">class</span> C extends B <span class="br0">{ </span><span
    class="kw2">public</span> <span class="kw2">function</span> foo<span
    class="br0">(</span><span class="br0">)</span>: null <span
    class="br0">{</span><span class="br0">}</span> <span class="br0">}</span>
<span class="kw2">class</span> D extends C <span class="br0">{ </span><span
    class="kw2">public</span> <span class="kw2">function</span> foo<span
    class="br0">(</span><span class="br0">)</span>: void <span
    class="br0">{</span><span class="br0">}</span> <span class="br0">}</span>
<span class="kw2">class</span> E extends D <span class="br0">{ </span><span
    class="kw2">public</span> <span class="kw2">function</span> foo<span
    class="br0">(</span><span class="br0">): never</span> <span
    class="br0">{</span><span class="br0">}</span> <span class="br0">}</span>
<span class="br0">
</span></pre>
    <p>That seems reasonable enough; I may have missed something
      important, though.</p>
    <p>Regards,</p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------5gTV5N99HR0T5UBciazQVLjR--