Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127599 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 3B6931A00BC for ; Wed, 4 Jun 2025 23:49:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1749080875; bh=+UxKosHzaPfs57mYdCPCnrI5voWT9wJwKOIxCdOrO7w=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=G3JQv8i8NkWS5sQiLW3PnccPy9e/Xzc/9boxUygXA7Jlx4tSIelXdzgh6+0T10z+L cHZ5g/emmf+5oVoV88m9IKS8mdJiJJ01/3CFJgaLXzuLana3EC379FXi/wNAhNgtV5 mCNBLluaP+ji8hmdyBpBgm7sOAGueKaxrLpzsxG+Tv7ZbCJnfpq3eAQYp6t1hSuBaU wByiGFWJWLfnoW7KdSBaa/vikDxBpwdy8p3Hdn7zTcLJjqm+O2Y0MewWUDYXL+U/Ti Q4sUlZ8/ml4Dw4TQtrckPgu/HIXg9bdo4sLSYW0Y7wsldecAAK9PomkpgyBV0gdVBz 6nbuEbI45gaEQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 676CD180047 for ; Wed, 4 Jun 2025 23:47:54 +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=-3.0 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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 EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05olkn2028.outbound.protection.outlook.com [40.92.91.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (secp384r1) 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 23:47:53 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vrj1/csjPMO+Wne6OEQAG6TDkDLpy13q/MVAFfd6J/Ua/yaVLu6nKOysUYZfoPzRN9zFjYp4gMyIFV8X8tuSyRkcbjHGiU8i6EbPPvjRRcFMEs1nxPJ1tHIWKPu2qChtnLE6O8HSKJDTQC3QNnmLLg+ZUaJHWw18gJA9esjNSqKpE4nS01OrHB4C8JVP2NF0BSrkXjCQgEJFbZuLGFtGQGKn/fp9K8Vp8JXYYMtAla2gXKd3i7P93DJKKmfAHBy7BNgpUUXLzypojZmfqn9/AcXGJzZtU6y6ef8ef291pW6l+oaZo08vkO4vELN5cYvmbyiyKsxEOsZZHVBVjkAq6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Y9UbZvpdIE/flL990SbqqCECGEQrJFyH2JowvlDqglk=; b=Vnd6UPEX0qcKSGlDWs3rDyxwE78js0ENnora/o7T8+Ycbnh8jD+dINz8IPbI7uVp0VWIM6Vs/Nycc/rwNIEqndWGsDc9ONSj3tMA0Bb6LbxPJiujwtA/60VWF2S2F9OMp13yoZ308rhF9o/M7WrRmsHLiXrsiwCOeSoBM2zizZHy66XfhQAEo4j22BPghJxTJacdRwlavAIEHG0I+kKr8XMuuD876arNP9/jEGc3Q9OZRu5u/DGG/1sfb3eG9enPB9/brHn0k8Qa0iGJxyK5km3SzWQpk5eB4ctzV8oG2xY48NccfAgIy8pjOEDxKoqqA+semRvF9M5Yqik79Hf7yQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y9UbZvpdIE/flL990SbqqCECGEQrJFyH2JowvlDqglk=; b=XgY1lJwfyATrRZI9kFDSAHOMFB0rAGHc/9J6pU5vzM1ZlpMxR0QN6vZQx3C3XHcmgJ/l4vQqq/0cqJ5h46KQ1+kbflRySfJ7hLUUFX+kcu8WpYvzGAwPWaIVu788cWKJbSXJSHmiChk8WLvI94sh8O0MJJaJ2pWlJt69iz7JRTJpaQDqxGmOrFrojX1FSeStrvKaMTP2RFZ/efOd7S7bVqvEQmSnOqPXvWUQpyj689dxB6vfY6gJjk5kpUJWh36VNE4LsrYawP2CsQJ3SGhRftMZCCW07z5JhnCPJA7MMVWGY3A3Ov8mCS3kNeFHhTi3WndUeoNl7k1XO1VWA3g4EA== Received: from AM8P250MB0170.EURP250.PROD.OUTLOOK.COM (2603:10a6:20b:321::21) by PA2P250MB1070.EURP250.PROD.OUTLOOK.COM (2603:10a6:102:40b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.33; Wed, 4 Jun 2025 23:49:54 +0000 Received: from AM8P250MB0170.EURP250.PROD.OUTLOOK.COM ([fe80::651e:bbd2:b18a:80ff]) by AM8P250MB0170.EURP250.PROD.OUTLOOK.COM ([fe80::651e:bbd2:b18a:80ff%7]) with mapi id 15.20.8792.034; Wed, 4 Jun 2025 23:49:53 +0000 Content-Type: multipart/alternative; boundary="------------kA7DxPi0k11v90VDPAoFZlz1" Message-ID: Date: Thu, 5 Jun 2025 01:49:52 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PHP-DEV] [RFC] Transform void into an alias for null To: Daniel Scherzer Cc: "Gina P. Banyard" , PHP internals References: <6Z2Ysh6MjYp1nyzuB0bTPJc5srObIcMRqt731JaQeXUJk1f_V_Yo2nRn8WvjI7er7pp7pIUE6WYl5pRwvYrtcrd07nCutyAqKPSsZHmrS-Y=@gpb.moe> Content-Language: en-US In-Reply-To: X-ClientProxiedBy: FR4P281CA0275.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e6::17) To AM8P250MB0170.EURP250.PROD.OUTLOOK.COM (2603:10a6:20b:321::21) X-Microsoft-Original-Message-ID: <449555b4-db07-42c4-826c-ae6aca307b96@hotmail.com> Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM8P250MB0170:EE_|PA2P250MB1070:EE_ X-MS-Office365-Filtering-Correlation-Id: eba68519-f3ab-4604-2946-08dda3c28061 X-MS-Exchange-SLBlob-MailProps: cn60g5V53KPpxxTzryIFPVXG/KYIYqSUVe7BXh3gBs7HvCwNmNTi1wZmgl0nphxLIJGKCFY/xkgvwBmhsfOZnetBfvVzDAFERT0naCN5ccSgSGF3BzIAQBKLVA95IiIrSCR01JIhHLKwBMLPRHbP5kimgjCFe3utyEfuKekWBesi9oDtghlufoJH2JrVkKx2g2azru2KOiLTgLtklIOvUOYeeHVwISfsyzs5IgrX5Nw4Bsrezp49MMmUNL6S6kxW4EGNXItdpfJgf6hK6YIcPx6jfgmkyuMpNfZVl2iC7hxoi1sp23IxwamjqAUXTBctWgMUkYwHlX5hEIvuXW9mRvYENEMQxBdko8NGELV0sQuDDBxs/ECcyCvWG7g2TN/OyoDesbt1YeL6TlDeDcaxHw0i95HSY5mPDherXOYVsFF72FaPd2k+BPWLHg7j01UVs3ALzvVrPapiok4k5isZKstzKKQTf6IpdVM5s7NZhD5FGkio+VNrCRp0MlN4kzqEgHU7T7JItiqr5tbHTPbBOOMM0XETdxmYIHzsoeWu3r5ByGLyrkUKDLymlq+ekadUVCIpthiR4sHYgSOxba7F+MJtqkNCxbBnGbaOGQFWukhajKsa1Q+gptfkSVWC6wd++A74PF6+uygI7BchIF6skuRBcgvfz3a0qoc3ZKsJzHcdNw6nIArpTuM/rp3OjzA0Wi4HeiqUMObhTZCR+J5B8ghZ9l5U1lsk7TIucNvfjUpwlA9+KDHJfrfmZtDBGLZvNvdz76gmq9oefzq193EH0heUiMtg4VTEr8jUPSfJ0FDEAScN39uvC/rMBzPYrtsrrDEC4eU+3SyOYObPD2vmWxjGMZUtyHxG3fpBM5Giqr1FMDhQuIdGDA== X-Microsoft-Antispam: BCL:0;ARA:14566002|19110799006|7092599006|5072599009|12121999007|12050799012|15080799009|8060799009|9400799033|41001999006|461199028|4302099013|3412199025|440099028|26104999006|10035399007|1602099012; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Wno1QUpJa2lMM2lKNFN5aHI1L2xUTVVldlpmRmg5WFlaMWRUdzdzY1RFeUxa?= =?utf-8?B?YW9LOEp1dmllT2FjRlJBc0tFSXc5dnRZZWN3Qk5VOEl1YXZ3THpBLzJrT2xm?= =?utf-8?B?S2lCbFUvYitQdDZiQnVTSGFxUVJYR2hkRmxSYXBBVmdOSS83ZGZsQ25UVm5T?= =?utf-8?B?OW8rSmx6RmRnSldhQ0ZsZ1lJYWsrZThCMVFGcTJ4YnFKN24vbGo0NHVaWHdH?= =?utf-8?B?WlZHNWsyVXQvY0g2OTRyRkFMZ3IvL2VJb2FkZzQ4MzNoenZSWE5CVGRiMU03?= =?utf-8?B?ejR0Q05ENXgyUXB1VDdweHE2dW1vaFgrKzVidzRzWjFrNldNd3ZSWmFzY2d2?= =?utf-8?B?Ukx5bzk0emtWdFhXK01KZUdzcXIxQW55QWw5bkp4d3FkWUtNeDFGeE93K2Jh?= =?utf-8?B?b1ZVQ3ZYemhaRS9VUHR2ZzlmWjdFUmkwMTBjUG1kYnpyVkZhdXkrTGxieFVs?= =?utf-8?B?NmRWV0E5SHA1SzhNYVcvd1phQ2lsVm9ZZ2VoL1NOOFBnSHlaZ1FuUUpXUmFw?= =?utf-8?B?VmpJVEpaNHQ1TGRyd29OYlFseWx6TFlUVzlpbURtRnBaZGF0cDlEdHZIdjhi?= =?utf-8?B?ZnNDUmZFcm1xSU5La3lTM2JwRTlnbjJSOGlNK0NJTWdyd1hPTkNJTWlTeXhy?= =?utf-8?B?NVBqNVRaQmxSMm9sSllCdmFpbXNRSHZVbzdQbkF5d0dFM0NxSVdiaGdnY2Iw?= =?utf-8?B?MVpjVEtHdVM5OXN1YTdpa1lINURjQ2tsOEtvcXlBN256aWdtbGtaS3V4aDVx?= =?utf-8?B?bXFZQzFDaklqWGhrSWx1dTRoN2lqR1JVYlZrOUEzVFMyRWNoVWh3bGpjVUNB?= =?utf-8?B?azFuZG1SVmcxMDZwMzFJNFY2My94MEZmVFFER2VNSHNBSVZrZ29SMjB3TEJW?= =?utf-8?B?aFNxbEQvODNvcU00VEpMblh0WVhnOG5vMXFibE40dDFqbDErZEkwOCs2RWFk?= =?utf-8?B?TUhBaXp3bHNwczdMK0pZV3E2cUlDc3JGRFZSYlI1aWROK3pWTU5MNDRiVXFU?= =?utf-8?B?UUJHU1pZTXZEMW45c2l6eDBUOVI1TGZ6RE90VHVsczIwUzRvTmdCVThqSlNv?= =?utf-8?B?UnhlR1BGbHNjUDZhVlllMC8vazJaaFJhN2tLMTEzaFhHeXpqQ1JPNENBMWRR?= =?utf-8?B?OXBLMmZvSG9RemJ2bVFkNlVxOTA2b3U1SmJhMGpCRlVMR1d1UHljTmhEc2I2?= =?utf-8?B?Y1RDbEVNWWQrYnlrZlFuWWk1WUNNaWQ4R3lsMEpjYktVbU1UUUJaTmhjdHZj?= =?utf-8?B?QzBJS0kxUEtuN2N1ejd6blJMMUtMWGVFSXhRN20rbTFyZ2g3VDhiMk5SV0lj?= =?utf-8?B?NWxHSk5HdTI4ZVQzeWZwaHdiUmhJU1hTSFpxMGl0Z0szdnNwN1R6NTZLekpP?= =?utf-8?B?alBIb2VRWElBdzJURnZXeHdhclN4aHFQczhqWHZwRkNaeXIrMHJ3YUJJWXVy?= =?utf-8?B?clhMTzRubmR5SlcxUFIrUEFQdW9FV3UzUncyOFVEWjNPcmFPTGZhbFdZV1BF?= =?utf-8?B?SUp5NFVNOEk1TzJMNUJoU2tQVXVrOWFTYk5VTTFnUytOYTM2SG8yOENCUmUy?= =?utf-8?B?cTlnbmdLRjZBNjUxZFVzaDltUEtMM3J5ZXpxR3B2MzBoRWxPUmIrV2VQY1Ri?= =?utf-8?B?MXR4c3ZycE1mY0VPN2h1UFBjejkzdUpmckg0aWZOcXZxMElPWUFRc2FCVUtx?= =?utf-8?B?OUJZTXpYbjc1bWZhOFJZejhhN3UzcFluTkJGemU0RmUvVDVrMnZvenR4dmp6?= =?utf-8?B?WnhMb1F6bEZtMmNIbUU0elZWVWlBY2g4NWMwL1lQOFVNcGRsQTBxSXBhMVMw?= =?utf-8?B?OUNSRkp2dHI1Z2lTeXM3NytTL28zRXUzbFBrS0ZCMXdKQ2R6TUl0UWJGdU95?= =?utf-8?Q?yzY2um7mjTQHe?= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YVRjUjVEd2RWQUZId3pRVmYwbG1SK1Q2UVB6MHpud3Q0Wmg5aENndkFJNVh1?= =?utf-8?B?b2l0RllZejJPeDN0WTdRVGVldUMxQ0tGNnRIZDhyN3BtNjJNWVhjL3Q0R2lj?= =?utf-8?B?eFBYaEpXU0NiVEhyQUpWajNCUmt3TWxJZTY3dEFVSlN1dStEcVZOVVk5Rm5k?= =?utf-8?B?QlpxRWw3cU0yN2hnSldYMExCZkpaWXVYVCtaL0tISHJoQUtOUkljTXBkTnIr?= =?utf-8?B?U0IzcS9yUHFVQTdDV1JEWk54b0tJNEs5RXphZXhvQVVUSGZ3bTJmejRsVGl1?= =?utf-8?B?RC9Ic0tCNDNERHplWTBFYTY2cTZ6Y2w0QVE4VllhWE1qMEpEMmUrOFNFQTBv?= =?utf-8?B?M2Rva2ZUUVNETEJBRkxpTGJ5bFVzYmVRN24xQ2psd2J1d0ZaaGczTDZwbzNF?= =?utf-8?B?VTJWNm1iS1I3eU05ZXlOV2s1QjFpQ3BGSlJzK1JOanMyZjFXU09LVldDakQx?= =?utf-8?B?VmRya0U0L3U5em9jZU42K0JkMjY1QTBzR21lMnRENzFsbUdsbDZDOGdBSEhx?= =?utf-8?B?d1NaTDRVNlQvd2hRTVdieks3d3NQUm9pV2RuTkYyMlIvV3RkbHlsNUtQeUxq?= =?utf-8?B?MzFicEl5MFZodUlvQ3NIL1hnT0l6OUlBN2kwOXdBM243ODRlS2QvbForMkp2?= =?utf-8?B?RVNtM3hOQVdEd1RBczJHNzdUNHJOc2FsSHpOcE11QUtIVjJ4SDNMOENKYm9s?= =?utf-8?B?cmZMOGJHNGpFdmlvWnFMb0V0RFRMSjdQOURjSVVwMDRXUEhFdDNOMkowaERX?= =?utf-8?B?ckM3cXdjckYvMHU1c01PN1l3bURLZVVRR1lZUTNBSFJMVXVLcGEzTHFBOEpi?= =?utf-8?B?UERJUlZCOFk2Wm15VGEwVzJ5YlhKazBlZDluVVZ6bmFoYXVWQVIyenRpeDJo?= =?utf-8?B?Y3MxNlAwdVNOUU0zQlBIbzFveVRTQUpBTlYyU1Mrc3pEREE3SW4rQmtHc0tH?= =?utf-8?B?VmJQekk5bGMrZUdBYTc3N3NYQnJZdDZsMTQvdzZ1VDRJVWFCbWJsNytXTSsx?= =?utf-8?B?RGh3MlRKT2dzR2RrcVlqanl5Znhwc3VGcEFDL1h4N3NzTHFCK0I2VWtPVTdh?= =?utf-8?B?RVNvSW8zVGZOVEQ0bElwSmlCS3BrN092MlFkUGs2M2ZWTWtyV2krdWtFWUhr?= =?utf-8?B?STVldWVpWUwwWE5HSUo3SEpYY2xob3BXQlpnKy8wTVZTUEJxc2VjMFUwQnZD?= =?utf-8?B?OEJ3V3NQMWk0VnFxZ3pVck1kdmRFcVFmK0pTQUt6bVV5ODdDdk0vNk9hQ01Z?= =?utf-8?B?L3Q4Ty9BV3FQNjhJOXhoK0Q1NkFDWTdXaTRLWG5SZHd4S0p6bWw1VFhVZUYy?= =?utf-8?B?a2JKaVJqL3pDZnVyWW1MekNzaUlKbFF5VW80WmZaZHZENkpDVkNqNkU4dnVV?= =?utf-8?B?U2V6ZEQxNmFzT2MvVTY0aFdOTDBHSDZZRVc3elNPb3RhSUpIdzJiME0wTE1p?= =?utf-8?B?UHpRekkzQzBiTVZxai91ZnM2c0g1N0dTRmxHSytDRmNXZzVZVkY5T1lTL3JU?= =?utf-8?B?SGlYWVlDRDA1cUFldWYvOHc3NWJ0aVdHSFcrelJ0QUNnVThKeXErRGI3WDhZ?= =?utf-8?B?c1U0WVhjNjJ5dHpsR2xQNFNxcnNSVVlEQmpMMTVVMmk3NUd2Q3Z6dWc4WkRq?= =?utf-8?B?Vkl6dXoyVDU4VFFLRHNEM2tPZzN4QXJwSGpMVTFCWDZ4cTdxTFpYYWh1aU4y?= =?utf-8?B?Wmo3SldTL3E5ZVlmaHJ4TEQyNWx1UkhwN2hxNnluQXZkcG10d3ZOeFRvemIv?= =?utf-8?Q?DKomNI5cMkGzO1uhdQ=3D?= X-OriginatorOrg: sct-15-20-8534-15-msonline-outlook-5f066.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: eba68519-f3ab-4604-2946-08dda3c28061 X-MS-Exchange-CrossTenant-AuthSource: AM8P250MB0170.EURP250.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2025 23:49:53.8089 (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: PA2P250MB1070 From: bobwei9@hotmail.com (Bob Weinand) --------------kA7DxPi0k11v90VDPAoFZlz1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4.6.2025 22:39:28, Daniel Scherzer wrote: > On Wed, Jun 4, 2025 at 1:35 PM Bob Weinand 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, 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" (= 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" = "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 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. 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). 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 --------------kA7DxPi0k11v90VDPAoFZlz1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 4.6.2025 22:39:28, Daniel Scherzer wrote:
On Wed, Jun 4, 2025 at 1:35 PM Bob 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, 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" (= 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" = "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


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.

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).


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

--------------kA7DxPi0k11v90VDPAoFZlz1--