Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127597 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 3F3C51A00BC for ; Wed, 4 Jun 2025 20:40:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1749069476; bh=xgRZJJjd0K1gbikQOo7JryivrjAd+LwcnmvYLOJpgoY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=O6+QTk77FtFufhMsUQyAQZ2LaLfH70jWQ5IcyTymkSglsNDlQcGGYKOWzRhRHqy+x c1dYByA0U/FY9AnqQ+EkYwRVUAL1SSBNZpN9qEpzBnx/f3+qltdpCljJjJXrRVA6IW UZFoz0r2lrc3oKrjZSxJK5qvU4f54oFJeEtBQl4gyjlHgCpIYFljHD+uRBUj+2Er23 PV9uM1cWUy9YvyJWRxQY+BwcHdRpoMO8qJGaHKjecq5x2DGbYA8rn4dvVNmAPMSYAZ g+IuDjvPkza6jaFfD2eDg1GSlVpfVAU0N0CTWt/9d1z16aJu8lWHJtb8RhKQQ7xHAI celGW/aWHqvZw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8B93E18005D for ; Wed, 4 Jun 2025 20:37:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 4 Jun 2025 20:37:55 +0000 (UTC) Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-e7dc89108bfso279821276.3 for ; Wed, 04 Jun 2025 13:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749069598; x=1749674398; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xgRZJJjd0K1gbikQOo7JryivrjAd+LwcnmvYLOJpgoY=; b=S5Ykykn3CfdFHpO83GFhwdpQsCPc9lo0ihNylF8UKXZoJVrLtpxKRHNnr/hIXwrc/3 dLkiIMtV8BSBFtqrB1wSZ9ZK8jkpt87lg7dvi+0cpDUnDnJJXR2uh9WPKfob+m6b+qnd TNfufA47R83zhTyzh0hoMs8Se/GqCBGg/sSC7UKZrHUg2zN8wkbOs0MtdaPQoxYFAt7J pA1w6oyvxBjhIKGMi4As6N98uDcWyO1crmXXGDK0dRIHKXOkVGIWaVWdetIdPEw+7I6N t9/a+W86rUKJfZRqScE/igb9v8pkDGY59AY35dkzAJtAL5BxMhZbEY4yK1YxUmXSZD2u dbKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749069598; x=1749674398; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xgRZJJjd0K1gbikQOo7JryivrjAd+LwcnmvYLOJpgoY=; b=Siq4tOyKW+aO12+HuIxmwWPRf1ji06HkNyaz9WUG2GZ7+lZM65VENddQupNavwy3Bb nP8E6exqtBnECTsAO6gl2pyWlwBbf0h4V9IcYCRBXuP9KXGGID3zRHRNjW/yC9IfVEx0 kTaI+C12q6eW7eEbuCSBAAg1n2gT9srf5gAWNmXJpkqgML2nUuuVLEeYjJvESBeqPbPr ACf6IeYcJOTqTWwWmKp9VufREDg/7Ly5jEe03YqFSjz49Z3eKX0qdve+mrg/+hVtV3zD iNQHEbpjPHuxgoyyv0r/OV9qi9K6Qc9VdIVGEK6PvixFCl1XjlvCMllNv8HzGo+Drjd2 o/sg== X-Forwarded-Encrypted: i=1; AJvYcCVX64I8gAmrwBq6aSwRgFzDpMImlz66E8yPRVgvPNSb9rK34H8aph6Of6S9+yzEzOjnhBIcp/6gwNU=@lists.php.net X-Gm-Message-State: AOJu0YxFQUg5M+z9AqfcsdiYBiO2ft0NjdRNE7QQ/ky7jwDr+ihxFTQr xIZ/2qwSLofUVK0VI1ChU8jYAVhBW7pbDrAaNDoK/Q/o9PIAVmPSkPaQAnHvRTT9qUVOdTdT1vN Hn/iB+8JZu8wqqlk8oQwZU6OuvN8tL01KHl3k X-Gm-Gg: ASbGncta6+fKZub3uhvYttcjX0wzQkFGEtvF5CKQSdiTA2kiwwA01R71gw92TjVbI0f ZpXPwNJF+xRuQ6wlcostAvKtGrVHXhPyg4XwQF0FtxkO6zxNIP/j3wbcNDlR6X6Cm2FWemTjLtW p4qCGCdt1KiDahxkdYKBil/OQLsbcxHP6qiOz3rAupbc643A3VbCY0wZPzyDjWaGkbvEPD5hR6v Z8= X-Google-Smtp-Source: AGHT+IH4iG6wWKJ6+Hq7R1qU3bnwc6wo1ipAKoqR1giLExbcV6enM0aZFa6pp/t6zHm1gfjaS5Wu9BEfoA4SHH4PKA0= X-Received: by 2002:a05:6902:1102:b0:e81:7e16:aacd with SMTP id 3f1490d57ef6-e817e16e726mr4389691276.2.1749069598414; Wed, 04 Jun 2025 13:39:58 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <6Z2Ysh6MjYp1nyzuB0bTPJc5srObIcMRqt731JaQeXUJk1f_V_Yo2nRn8WvjI7er7pp7pIUE6WYl5pRwvYrtcrd07nCutyAqKPSsZHmrS-Y=@gpb.moe> In-Reply-To: Date: Wed, 4 Jun 2025 13:39:28 -0700 X-Gm-Features: AX0GCFs2_lxmVCeoxSUYNASiFIAr1cqUQjHASuKKEqQHsa7Uk4T1PBOh9qQBmZE Message-ID: Subject: Re: [PHP-DEV] [RFC] Transform void into an alias for null To: Bob Weinand Cc: "Gina P. Banyard" , PHP internals Content-Type: multipart/alternative; boundary="00000000000019dbc10636c500bc" From: daniel.e.scherzer@gmail.com (Daniel Scherzer) --00000000000019dbc10636c500bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 4, 2025 at 1:35=E2=80=AFPM Bob Weinand wr= ote: > > On 4.6.2025 16:54:05, Bob Weinand wrote: > > On 2.6.2025 18:27:51, Gina P. Banyard wrote: > >> Hello internals, > >> > >> This is the second RFC out of a set of type system related RFCs I > >> want to propose for PHP 8.5. > >> > >> 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. > >> > >> Let me know what you think about it. > >> > >> RFC: https://wiki.php.net/rfc/void-as-null > >> > >> Best regards, > >> > >> Gina P. Banyard > > > > I have to agree with other posters here that the distinction between > > null and void is an useful one. > > > > In particular I'd consider the null returned by void to be incidental > > rather than intentional. I consider the return value of void functions > > "some arbitrary value". It just happens to be null. > > Like every function has to return something. But returning null is not > > an intrinsic property of a void function. It's an extrinsic one. You > > observe void functions to generally return null. But that null in > > itself is meaningless. > > > > So, my counter-proposal would be allowing covariance with void and > > allowing everything, including non-nullable types as child type of > > void functions. > > I.e. effectively giving void and never the same semantics, except that > > never also indicates that it never returns. > > > > Additionally I'd be in favour of disallowing (e.g. E_WARNING) > > consuming the return value of _direct_ calls to void functions (with > > the exception of standalone direct calls in short closures, because > > consuming that value is intrinsic rather than necessarily > > intentional). (Disallowing indirect calls would be detrimental for > > usage as callback.) > > > > Bob > > > Clarification: *opposite* semantics to never (which is the bottom type). > Void would be effectively the top type (only inferior to untyped). > > So, it allows child classes to then return a meaningful value when the > interface was just "void" (=3D no significant return type). As an example= , > when the interface says "set($val): void", the child class can specify > "set($val): mixed" and return the old stored value. > > Basically, an interface can now say without further clarification "I > have no real return value" =3D "void", rather than having to say "mixed" > and then explaining "this is not really mixed, but whatever you want". > > (I have seen interface method return values being "upgraded" from void > to mixed (or just untyped) in the past, just so that a specific child > class can now return a meaningful value.) > > > Bob > MediaWiki's hook system (https://www.mediawiki.org/wiki/Manual:Hooks) has two different kinds of hooks - those that can be aborted, for one hook handler to say that no other hook handlers should run - those that cannot be aborted MediaWiki uses `void` return types to help enforce this system, where hooks that cannot be aborted must have void returns. See https://www.mediawiki.org/wiki/Manual:Hooks#Hook_handler_return_values. Making it so that any interface function with a void return can be implemented by a function returning anything would seem to be a huge B/C break. If you want to use the top type, why not just use `mixed`? -Daniel --00000000000019dbc10636c500bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 4, 2025 at 1:35=E2=80=AFPM Bo= b Weinand <bobwei9@hotmail.com> wrote:

On 4.6.2025 16:54:05, Bob Weinand wrote:
> On 2.6.2025 18:27:51, Gina P. Banyard wrote:
>> Hello internals,
>>
>> This is the second RFC out of a set of type system related RFCs I =
>> want to propose for PHP 8.5.
>>
>> The objective is to fix a weird quirk of PHP's type system, wh= ere
>> 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.
>>
>> Let me know what you think about it.
>>
>> RFC: https://wiki.php.net/rfc/void-as-null
>>
>> Best regards,
>>
>> Gina P. Banyard
>
> I have to agree with other posters here that the distinction between <= br> > null and void is an useful one.
>
> In particular I'd consider the null returned by void to be inciden= tal
> rather than intentional. I consider the return value of void functions=
> "some arbitrary value". It just happens to be null.
> Like every function has to return something. But returning null is not=
> an intrinsic property of a void function. It's an extrinsic one. Y= ou
> observe void functions to generally return null. But that null in
> itself is meaningless.
>
> So, my counter-proposal would be allowing covariance with void and > allowing everything, including non-nullable types as child type of > void functions.
> I.e. effectively giving void and never the same semantics, except that=
> never also indicates that it never returns.
>
> Additionally I'd be in favour of disallowing (e.g. E_WARNING)
> consuming the return value of _direct_ calls to void functions (with <= br> > the exception of standalone direct calls in short closures, because > consuming that value is intrinsic rather than necessarily
> intentional). (Disallowing indirect calls would be detrimental for > usage as callback.)
>
> Bob


Clarification: *opposite* semantics to never (which is the bottom type). Void would be effectively the top type (only inferior to untyped).

So, it allows child classes to then return a meaningful value when the
interface was just "void" (=3D no significant return type). As an= example,
when the interface says "set($val): void", the child class can sp= ecify
"set($val): mixed" and return the old stored value.

Basically, an interface can now say without further clarification "I <= br> have no real return value" =3D "void", rather than having to= say "mixed"
and then explaining "this is not really mixed, but whatever you want&q= uot;.

(I have seen interface method return values being "upgraded" from= void
to mixed (or just untyped) in the past, just so that a specific child
class can now return a meaningful value.)


Bob


MediaWiki's=C2= =A0hook system (htt= ps://www.mediawiki.org/wiki/Manual:Hooks) has two different kinds of ho= oks
- those that can be aborted, for one hook handler to say that= no other hook handlers should run
- those that cannot be aborted=

MediaWiki uses `void` return types to help enforc= e this system, where hooks that cannot be aborted must have void returns. S= ee=C2=A0https://www.mediawiki.org/wiki/Manual:Hooks#Hook_handler_re= turn_values. Making it so that any interface function with a void retur= n can be implemented by a function returning anything would seem to be a hu= ge B/C break. If you want to use the top type, why not just use `mixed`?

-Daniel=C2=A0
--00000000000019dbc10636c500bc--