Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113908 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 55519 invoked from network); 1 Apr 2021 13:58:02 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 1 Apr 2021 13:58:02 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C694918053D for ; Thu, 1 Apr 2021 06:55:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 1 Apr 2021 06:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1617285346; bh=mEPsuJhc3ec9yGk/JQ2pFpm/KVXYnw5NXAVFriGlhr8=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Q/hpmbnf/ExBXH1PvtnV9GiyK+hpRR60OPkX5wW9mWnbiswzn6avQGLwz+T2aTb1M LWzoIYIj5BqoDbUZ8XjkImOChZoivcEr5NHdiVnYrzF3ltl/jhTEhCGsdS2C8QJjar c5K9PtYkz3uLkWelIycLjVESvCv1Zu3gfJi6SvDc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.120] ([24.134.51.41]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N2V0H-1lbytZ1atL-013uJi for ; Thu, 01 Apr 2021 15:55:46 +0200 To: internals@lists.php.net References: Message-ID: <7399011c-a638-5363-5303-c01ac402bb92@gmx.net> Date: Thu, 1 Apr 2021 15:56:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Provags-ID: V03:K1:58e/OOsGH8xFkzUzJCTWBlbw9wqA8YNfIMMmtopkS4LJ+Br5Eab w347BiIdzKWfLTvxPlrMiB4m1P/oKzsQdEVM5+bvcVjcvyeqqrO6vPk1D8o4GPGGXbig9Dc zadixfxA6Kjy8sNJj/kKtXWjXWU/SNO4CR0A9KwzHkMqkpI0LVoWeTIlesmZ4SUkvAJqWxB P8ysdrRJaCuq/Wm4+oVVQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:92cjMyIuP1M=:CAchuDCbjb7fj32JmFT2yb AL+8m86Ncut9IdclhzLD42Q/DrB1fqxBN817ZuJwqm/3klNXbw7i7rzHQ8wqmae9SC1v4BdaG h7yY8dCXsqMQrZUhpUTmLHv09UCOeLGkZ51OJEsT3yR0nRyfaHBqeLeFWtxw8JlhtHpYhvKcS 0TwvVvPIM3zKAID6XzmcoKNJoFl+TteA28L0twCpuiaLvr92ZDk2xOypto9Z/IOM1h2y1f9oP FSrPjuki4u0ivoC0wyortpIukAgkMhs9G3Ixc3UmzZAYY28gG8WUUX52ZdqQKUQhYGiiKDuNX erlbnnbZe1IAaHDdtA0CR8wE+3SnlMxbJt9jVWN/Fwep7dxfin5r3VKig9kbALYEEZQ37yQ+u XCGx8Sc9lhOjvcNr9HXzCIlUZRqkrYCTgWf0kam0FNE7XUlBRfOfp/ZwtPJr4mNjX7bSP2PDD RpmJrz485Ow4rldOTMGaAyqZ+NORawYilC0vfveMAEC4UoGKeaCStIq7K8+O41r5Hs0LP4lCa 9+y5FYdxbrv9y8gJxzYU7CEHtob4g24q9f39+V2zBpJOawjveEDTUhpq1oXSiXPsPsqPBrqSG p7+Mj8qT/QTM7Ib4aj51h7tPvPS57Mcycqqt909FdUe7vxr+h06xkkSBDgyFt2OHon8hn55M+ CeSwoVLnNG8dXOa9upxFz/v+VTgLpio84qrO/LCkVZaxSpMItv5BNbdtd5UkAVV3a1gofL3oO bnd4VnzdtCyx/cgdeujoLwPoQp3B0GAwGmitJnZh7Idb3QwC/dpZe0hDWrk0krrfC1IvikJMp OenkaTe24HOLh1c1mt8opfFewHVNeQiDp2uDfp7yYqX+TeOIPUhDz0dNrFBf8q4Xt0qQDt0nl lccTXaNRAnYzvPEyjn2GoDnpObcGT3fg3qqXVaGeoVOnSGc1weh9o8IzFnqefJBxG1So6w3l+ jJRLkw4is4faCBmKh7y/gZde3f/ro8zXoR0iFPwmPf70HltiJGbu5RaJlCq37BQ/0rr9TQHty cVyqWAAyfYKLlZ1FeptfZjZjFarv98fprJm4IVG4gUj/lRjBeNiZqVxq4nIU7IdNea8w00ZFH yXAhztoGWlw3PlbsY6w4W/Gkoq03PfDFsnibswNSwPbTrXvxnYYWmWzYAYjplpWR/h0audlgR dEaeuAKj7ujViQOG6uxxGGNeuAmH/Pq+Uj6CkJfbeUuNswjtKKuMTQIXMIOhz1dT7igks= Subject: Re: [PHP-DEV] [VOTE] noreturn type From: a.leathley@gmx.net (Andreas Leathley) On 01.04.21 10:56, Benjamin Eberlei wrote: > This RFC is using the declaration of the return type, to specify that it > never returns. As such noreturn or never is a keyword a long the lines o= f > public or final, but it is not a return type. > > I don't think the argument for potential optimizations in Opcache to > eliminate dead code or allow IDEs to hint at dead code are valuable enou= gh > to justify this change. I already use @return no-return (supported by Psalm/PHPStan) in my code now, to clarify the code flow, and for me it fits perfectly for return types, as not returning is also a result of the function/method. Having a return type of "int" or "string" (or even "void") seems misleading when the method will never return anyway. noreturn/never might not be useful in all code, but for some parts like in a controller of a web application it makes handling redirects, authorization or 404 errors much easier, clearer and less error-prone, for example: ```php if (!isset($user)) { =C2=A0 $this->notFound(); // this is a noreturn/never method } if (!$this->isGranted('adminPrivileges')) { =C2=A0 $this->notAuthorized(); // this is a noreturn/never method } ``` Adding noreturn/never on a language level would make sure calling "$this->notAuthorized();" never continues code flow. This is often also a security issue, as seen by an alternative way of handling the above use cases: ```php if (!isset($user)) { =C2=A0 $this->notFound(); =C2=A0 return; } if (!$this->isGranted('adminPrivileges')) { =C2=A0 $this->notAuthorized(); =C2=A0 return; } ``` If you forget a return, suddenly you have issues. So even though noreturn/never is a niche language feature not everyone will use, it does address a very real use case. Using attributes has the disadvantage of not making the intent clear: ```php #[\NoReturn] function notAuthorized(): string { =C2=A0 // Some code } ``` Now you have a return type of string, but also the information that the function will never return anyway. That is confusing, but will be inevitable in some cases when implementing interfaces or an abstract class. In my opinion, the string return type is wrong in this case and can only mislead a developer.