Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127609
Content-Type: multipart/alternative;
 boundary="------------NMxpA6yxPxcaEnr5pi4xnjD0"
Message-ID:
 <AM8P250MB0170F748CC441A12A341AF29E26FA@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Date: Thu, 5 Jun 2025 14:00:53 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Transform void into an alias for null
To: Daniel Scherzer <daniel.e.scherzer@gmail.com>
Cc: "Gina P. Banyard" <internals@gpb.moe>,
 PHP internals <internals@lists.php.net>
References: <6Z2Ysh6MjYp1nyzuB0bTPJc5srObIcMRqt731JaQeXUJk1f_V_Yo2nRn8WvjI7er7pp7pIUE6WYl5pRwvYrtcrd07nCutyAqKPSsZHmrS-Y=@gpb.moe>
 <AM8P250MB01706610DDFA64C076D226F2E26CA@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <AM8P250MB0170B58BD2D303BC419ED3F1E26CA@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <CALaXqqQCQDAuUR6y0hP1en-XYA-kBD-261ff2GFoo55rqaqdoQ@mail.gmail.com>
 <AM8P250MB0170D7A9787F295E0FE5E40BE26CA@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <CALaXqqStkGtns6Y8=KZZVsFbsKm69wr4N-4j5d30ocMOP8cR7A@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CALaXqqStkGtns6Y8=KZZVsFbsKm69wr4N-4j5d30ocMOP8cR7A@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM8P250MB0170:EE_|PRAP250MB0616:EE_
X-MS-Office365-Filtering-Correlation-Id: d4e0059a-d6f1-4faa-cfeb-08dda4289fe9
X-Microsoft-Antispam:
	BCL:0;ARA:14566002|461199028|5072599009|9400799033|41001999006|8060799009|7092599006|12121999007|19110799006|15080799009|12050799012|1602099012|4302099013|3412199025|440099028|10035399007|26104999006;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?N0xTaHR1ZE4vRStwOGFtZEF3VHJuTCtHUU1WeXVQSXh5bThtYVcyK0tUT2xi?=
 =?utf-8?B?RUJvRW5zRTVYQlAvOWZNODk2eXQzVmY1SjlmT1pDaWR3cDFzeG82T0hBTVNJ?=
 =?utf-8?B?ZDAvb0lRbk9NMVA3QTMycm9kcTdINnVmT3BEUG5rV3RVWjZTVFdnUG15dS84?=
 =?utf-8?B?MXpZZ1lyN0hEc2xRY1EzT0V2UFJjZ1p1QzBPSyt5N3oyS2FGWmpDOXV5L25U?=
 =?utf-8?B?M0FQZHd0dG5oS3dSbE9oUjdFUk1sVjZEY0RZd2ZicENLb2NuVzRJYTh5NUJJ?=
 =?utf-8?B?ZG14bnVFKy9LL1BEYzJZTDJRTGlhWGMwbloxTnRjRk1sSHRvc2ZOOGJtU2NJ?=
 =?utf-8?B?T3lwYnBidk1oSGlMWVdiaXZhcENRcEVHdXRINWwxcURjV3dveUROMGVOWjha?=
 =?utf-8?B?MEpxaGV1NHpDK201K1pteE1PN2gzYU1QTGc3VUY2c0JGbm9PWGF0NlloTktP?=
 =?utf-8?B?d2xuM3d1ZnZCdkpSbEVKWFNwTUdRWURnZjQ5bzZTbEhJMWsxMDdqRkVYNlIv?=
 =?utf-8?B?NUo1aGFQOTNMS1NodkNDWitnMGFYalZUcEJwREZZOHJBanJQZ016VUlWYWRp?=
 =?utf-8?B?UWgvL2JVSzhUbERvMUFJUWlSZGhudCtROXhtMUlyZ2tIZGI5dThrZnE5L2E4?=
 =?utf-8?B?YzB4L2pLVHdQSlFPSTJrNWFSbU4vckU2Y1dUVTRDVDNNSEJVb1Vpak5xenRW?=
 =?utf-8?B?a1prZWc0OWkwb1RBem04QTFVZHBGR3RXSEkwQTZvc01CcmhHUXpleUlQSDhu?=
 =?utf-8?B?SFRjckZZM2I0dmlnTHEySWREbWhCUUYzOHhvYkh2M2R0RllIZWpZZGpQcHRl?=
 =?utf-8?B?bzZjQWJ1cDZPOGdLU3pBK24yd25ERjBlVnRjdGVFd2ZVREppcGpBOFNXV2tB?=
 =?utf-8?B?NmJvN1dia3V1Vkw2VWsxL3BRL2pmamdZSHdxOUpJV3lIS21MVTlVK2x4aHVS?=
 =?utf-8?B?MTFhV3RFczVyS0tHcEVacTVFMUtUR0NnYWVsUndLV2FPZGVnMjlBcGtTWXdO?=
 =?utf-8?B?SWdxc1VMSjRlanVhRk5hQXQxVG9zOW0raW5GeU9HRTEzWTRJa1I5RHhWc1o1?=
 =?utf-8?B?WnpvSVdBVThKbWlNN3pFUW5nNHJ2cjlsZkVYQU82L0dubVNNVTNnWndZd3Bm?=
 =?utf-8?B?MHBWenQzWnF0YVc0cUlyVlJ2eUhXM3RVR2lzY3lOYmIwNFNXUWVlZXVMZ1lB?=
 =?utf-8?B?bGFzQWVaaXlkRklKMUp6SS9kQmswWC96QVJ0RkJFSXQ4TDE4cDk0eERsSHlx?=
 =?utf-8?B?U2F3WjNSdDlWbVh6R3h0cjlIZENlME9wRlJtMU5XZjJUVTNyaUNkeittaE5G?=
 =?utf-8?B?dWtiQkpzOTlMVXBlOGlaeGxNWW5xVGxQNU1CUFErYUhNUmdpV3pFWDltQnhj?=
 =?utf-8?B?NTBIaUZVemtXMTdWcGE2MHJPNmh3cnJ0ZTJ0T2ZyT0pTTm9rUzM5SE5yYlEy?=
 =?utf-8?B?MHA5bTA1a0lZMnA0VllhT29adUhFMXIxMTF0TEJLa09McHliTC8vQVV1aEJ0?=
 =?utf-8?B?SWNEVDArOFpXN1N6ZjNPSUdTaXBQN3FvdW05RGg2MGtpa2JQMjVVLzVaSi9y?=
 =?utf-8?B?QW4xQno1UFFYR0o3NXRLQm12Z3JhMHo2SU1VdWZZZU9KWDBjUmNYa3hwS2dl?=
 =?utf-8?B?RFhmRWJmWGs2UGZ6THZpVnJkWGNka0dNZmkxOWRZM0l4cVkxMEpraXFvd3Z6?=
 =?utf-8?B?QW5SbnB6eXVkeVRVdE1rZVM2bzdOaUptZVJycFBoNUFKdkVzb1VRTXVKQXNz?=
 =?utf-8?B?TkNud1VObE4vSkdEUlZQUzk5akN5Tk9HUVJBcFRheFZ2c3djT2pDTG83RTBl?=
 =?utf-8?B?TmR4ZVdxNytOT1hFVzYrUDJmRlRmQ1czTzBFRVpsZWZmcVd6RWdhdTROOVdD?=
 =?utf-8?Q?JJlBCwUmD/Loo?=
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?a0lLRVZsaTE0Q29QWTN6dWdKQnJIN3cxdTR1ZEFtckxTZWdvY3hrbWNOaWVT?=
 =?utf-8?B?NGpNOStEcTRoTkNjNURwR055WU5NT1BsYXNpTWdkSU5rYVdqQjhGWEU3YTFk?=
 =?utf-8?B?ekpBYWJWUlpRTjFIVGVscUF6RllXTk1JVTE4TmZ2WmYvSmlGL0pHdjNXVm9W?=
 =?utf-8?B?MkhyQWFHZElHdnVLVGFzL3hYNldpWlhiaVRQUngzUDkzdEJIeUNKT2pnTS9j?=
 =?utf-8?B?YXY4eDNiajViZU5nQitVMFFJUGUydUVZS2JqTHRCT2JLNElsQ3pSWFdvSmFn?=
 =?utf-8?B?eVArR3ZjNUxrMDdSWkRWQVFoem5RMmU3bC9RbzdmNXFtckQ1eHhjMEtUeW1I?=
 =?utf-8?B?MEw4SWlTbFg0SjZQNXVYY0JDY2crZDdVNnY0cktlbkFyNTRyOUErYzI1b3Zk?=
 =?utf-8?B?TTJsczZ1bmZsV1hESXBPTHFsWXVmbkk4b0M3R1JtcWdmOGdqdU9aYktYeW84?=
 =?utf-8?B?dE8yUDlUSFpSelhLNVhIVFdVL1p4bC9LS0pXUlRyN0phYjhPREptQStlWnFT?=
 =?utf-8?B?U0VnK3FmTTViYzhHeGR2N2QxL3VhTm5iSHBsK3FiR0VVTlhMUmFQTExWS05p?=
 =?utf-8?B?ODc2bVdLaDJ0d3ZjYXlwMDBkOG5UWUpiM3U0Y2NOR2s4SFFwZFNzclY3YlE3?=
 =?utf-8?B?K2xENmNvckNKT1FDRUViaWRvM1M3cUNZUXdrL1NaZnhpL08xeGRRR09BZGgz?=
 =?utf-8?B?b2NaMUZIdlJkQkxpYW4ydXVYY1RWbmJEbjd3ZHpEN3F4OHhCWE5icnhxeGpZ?=
 =?utf-8?B?RVFLcXBDM0JSTUdtZThaZkxlajZtU0c2MUcyL0NSY3pmWWxLcXUwTWpKeGNv?=
 =?utf-8?B?dWE1d2lsVWw5ODBlYjQ3WTdPbkk0SVMyM1gwOFVyZTdpRWxGT05MRUVidnJM?=
 =?utf-8?B?aEZVWUs2VGF6dm1WU2dxeS9Hc05wZ2Z0VkRPbExtZHZCc2FLMThBdlJtM2w0?=
 =?utf-8?B?eUVUMTVHcDE5YmFtMEp2K3lyRnJLWlNGaFE2cWtIeTVaZWFkVVlad0xGMTQ5?=
 =?utf-8?B?WmlQMkhwQStyQ1BIc2paYU5jK04vRGVmVWtoMUdvbExHa0NadFZtMlBYV1VQ?=
 =?utf-8?B?Q1NDOTRHaE5uQlpXMnVXbnVQVkdtYzlVQThGc3BKS0R4dWZyVkZNSWxsNHRH?=
 =?utf-8?B?TzA3ZUcvNEdIQ3pSRklTSTVvbjAyWUh6ak5waGI4L0d6VUJRaHFQU2U5SDd4?=
 =?utf-8?B?VW1jdC8rRlFIVXoxZlNIdk5HaTUxNGNXTW0rNlRTWU1hdW1nVFNVNnlHS0la?=
 =?utf-8?B?UTgwb2gyRDl3VGxUd3lmamtNcGlqOFJVd2JIUmxLRGIvbS9qcE1Ta3V3R0pq?=
 =?utf-8?B?QnBPSjRGUnU4TDVSYXRlUDJXYjdVWlluTndWaytVVmluSmVTc09ROWhRSmsr?=
 =?utf-8?B?Z21Dcms4dTNQampyV1ppWnFrTGJEdGg3ZURsVXhaYmVwbEMyL1I3M2pzbVNo?=
 =?utf-8?B?M2tjYks1VmZDNUJKR1pOd1FDRFdVQmJhSlljNmxLM2JyaDhVa2tFZU5wYmRD?=
 =?utf-8?B?dVVZWFhmRE9tc2dzZU0vZXNEUlIzNDJ3ZURyWUZWSDRmSEtISEVBSlVYOEVm?=
 =?utf-8?B?WUtVSTUyTWZnVlBDMFEvZ0lLSWhIR21LbXFyZzcyQVZpMEVSZ2hnQnVCcHBF?=
 =?utf-8?B?ZkVwQlNVV3NJRUgzZHY0ZVlqMktOWjNhQkdscDc5T0lpWW5MS2RDck1wV0Zj?=
 =?utf-8?B?SnVTbFVlWHhXSFF2YXJuNFMrVGtOY0t5VkxWNFl0dFlhN0JWa2lxR1VzQjVQ?=
 =?utf-8?Q?MamDsDOxPM6PIB1pQI=3D?=
X-OriginatorOrg: sct-15-20-8534-15-msonline-outlook-5f066.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: d4e0059a-d6f1-4faa-cfeb-08dda4289fe9
X-MS-Exchange-CrossTenant-AuthSource: AM8P250MB0170.EURP250.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 12:00:54.9403
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PRAP250MB0616
From: bobwei9@hotmail.com (Bob Weinand)

--------------NMxpA6yxPxcaEnr5pi4xnjD0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 5.6.2025 02:59:56, Daniel Scherzer wrote:
> On Wed, Jun 4, 2025 at 4:49 PM Bob Weinand <bobwei9@hotmail.com> wrote:
>
>     Hey Daniel,
>
>     where's the BC break? Nothing which worked today will stop working
>     (except you won't get exceptions in some cases). That's not a BC
>     break. The only thing which stops working is if it's intentionally
>     used as a guard.
>
>
> That (intentionally using `void` returns as a guard) is exactly what 
> MediaWiki does. MediaWiki has an interface for each hook, that 
> requires that hooks that cannot abort (return false) must return void; 
> https://www.mediawiki.org/wiki/Manual:Hooks#Handling_hooks_in_MediaWiki_1.35_and_later. 
> PHP is used to help enforce this.
>
>     However, in the case of MediaWiki they do actually _care_ about
>     the return type (and the caller of these hooks will actually check
>     for null/true/false). So it should be annotated ": null". And not
>     ": void". Explicit intentions are important.
>     They probably still use ": void" as to be compatible with PHP 8.1
>     and older. ": null" is only supported starting PHP 8.2. I'd assume
>     as they upgrade their required PHP version (8.1 currently) they'll
>     shift to ": null".
>
>     So, yeah, the guard will lose its guarding functionality (but we
>     don't consider that a BC break).
>
>
>
> Why is this not considered a BC break? You can consider it a small 
> break, but I think it should be noted in the BC section of the RFC.

It's a small break in the sense of workflow, but *compatibility* breaks 
are concerned with the behaviours of non-erroneous functionality. (Code 
with worked yesterday works today. And not code which did not work 
yesterday works today).

But sure, the RFC may indicate it.

>     Regarding why not mixed? Because the intention with mixed is that
>     the value is something meaningful. With void it's meaningless.
>     There's a semantic distinction (and it forbids returning). And, as
>     proposed, you could forbid direct calls of void functions giving
>     runtime / static analysis hints. With void being covariant with
>     respect to child functions now.
>
>
>     Bob
>
>
> If `void` is a top type indicating a return is meaningless, then 
> callers would have no reason to examine the returned value, and then 
> when subclasses do try to add meaning it might be missed. Am I missing 
> something? How would void be different from "the base implementation 
> happens to always return null, but subclasses can return other things, 
> and the result can be meaningful"?
>
> -Daniel

What LSP builds upon is "if I code against this interface, my 
expectations will always be fulfilled". If I code against the interface 
returning void, I do not care about the actual returned value and such 
my expectations are always fulfilled.

If I code against some subclass (or any of its children) which has a 
meaningful return type specified, and I'm aware of that return type, I 
may for sure use the return value. Nothing requires me to actually use 
the return value. It's similar to optional parameters "When subclasses 
do try to add optional parameters, they might be missed". That line of 
argumentation is a bit absurd :-)


Bob
--------------NMxpA6yxPxcaEnr5pi4xnjD0
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 5.6.2025 02:59:56, Daniel Scherzer
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CALaXqqStkGtns6Y8=KZZVsFbsKm69wr4N-4j5d30ocMOP8cR7A@mail.gmail.com">
      
      <div dir="ltr">
        <div dir="ltr">On Wed, Jun 4, 2025 at 4:49 PM Bob Weinand &lt;<a href="mailto:bobwei9@hotmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">bobwei9@hotmail.com</a>&gt;
          wrote:</div>
        <div class="gmail_quote gmail_quote_container">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div>
              <p>Hey Daniel,</p>
              <p>where's the BC break? Nothing which worked today will
                stop working (except you won't get exceptions in some
                cases). That's not a BC break. The only thing which
                stops working is if it's intentionally used as a guard.<br>
              </p>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>That (intentionally using `void` returns as a guard) is
            exactly what MediaWiki does. MediaWiki has an interface for
            each hook, that requires that hooks that cannot abort
            (return false) must return void;&nbsp;<a href="https://www.mediawiki.org/wiki/Manual:Hooks#Handling_hooks_in_MediaWiki_1.35_and_later" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.mediawiki.org/wiki/Manual:Hooks#Handling_hooks_in_MediaWiki_1.35_and_later</a>.
            PHP is used to help enforce this.</div>
          <div>&nbsp;</div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div>
              <p> </p>
              <p>However, in the case of MediaWiki they do actually
                _care_ about the return type (and the caller of these
                hooks will actually check for null/true/false). So it
                should be annotated &quot;: null&quot;. And not &quot;: void&quot;. Explicit
                intentions are important.<br>
                They probably still use &quot;: void&quot; as to be compatible
                with PHP 8.1 and older. &quot;: null&quot; is only supported
                starting PHP 8.2. I'd assume as they upgrade their
                required PHP version (8.1 currently) they'll shift to &quot;:
                null&quot;.<br>
              </p>
              <p>So, yeah, the guard will lose its guarding
                functionality (but we don't consider that a BC break).</p>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>Why is this not considered a BC break? You can consider
            it a small break, but I think it should be noted in the BC
            section of the RFC.</div>
        </div>
      </div>
    </blockquote>
    <p>It's a small break in the sense of workflow, but *compatibility*
      breaks are concerned with the behaviours of non-erroneous
      functionality. (Code with worked yesterday works today. And not
      code which did not work yesterday works today).</p>
    <p>But sure, the RFC may indicate it.<br>
    </p>
    <blockquote type="cite" cite="mid:CALaXqqStkGtns6Y8=KZZVsFbsKm69wr4N-4j5d30ocMOP8cR7A@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote gmail_quote_container">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div>
              <p>Regarding why not mixed? Because the intention with
                mixed is that the value is something meaningful. With
                void it's meaningless. There's a semantic distinction
                (and it forbids returning). And, as proposed, you could
                forbid direct calls of void functions giving runtime /
                static analysis hints. With void being covariant with
                respect to child functions now.<br>
              </p>
              <p><br>
              </p>
              <p>Bob<br>
              </p>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>If `void` is a top type indicating a return is
            meaningless, then callers would have no reason to examine
            the returned value, and then when subclasses do try to add
            meaning it might be missed. Am I missing something? How
            would void be different from &quot;the base implementation
            happens to always return null, but subclasses can return
            other things, and the result can be meaningful&quot;?</div>
          <div><br>
          </div>
          <div>-Daniel <br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>What LSP builds upon is &quot;if I code against this interface, my
      expectations will always be fulfilled&quot;. If I code against the
      interface returning void, I do not care about the actual returned
      value and such my expectations are always fulfilled.</p>
    <p>If I code against some subclass (or any of its children) which
      has a meaningful return type specified, and I'm aware of that
      return type, I may for sure use the return value. Nothing requires
      me to actually use the return value. It's similar to optional
      parameters &quot;When subclasses do try to add optional parameters,
      they might be missed&quot;. That line of argumentation is a bit absurd
      :-)<br>
    </p>
    <p><br>
    </p>
    Bob<br>
  </body>
</html>

--------------NMxpA6yxPxcaEnr5pi4xnjD0--