Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117529 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 99431 invoked from network); 14 Apr 2022 07:28:58 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Apr 2022 07:28:58 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 291CD18053D for ; Thu, 14 Apr 2022 02:01:09 -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_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS8560 212.227.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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, 14 Apr 2022 02:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1649926867; bh=4PxVN01topJD6Bap2xnKA5bJuIVxw5/VGEkKMjmgqC0=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=SiPZvF6BzliiVQs+Zr9mrhDbXEIfe2dOZl5//L04cSkPnWk1a2gUOslehqnMUbwE9 KJh+eDhAScHqjZb41LfwuOMSTCGUGigxBaqnFgP5yTqGWscMFYt2olmLfHVxsVHnbe Hl1iqjBpTC/aw56xz+vnkB5ZXvZ1O0gnc3W4ouYc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.120] ([24.134.51.41]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N2Dx8-1o5dqm3zCg-013ev1 for ; Thu, 14 Apr 2022 11:01:07 +0200 Message-ID: Date: Thu, 14 Apr 2022 11:01:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: internals@lists.php.net References: <2035695b-b6b5-5982-a5ea-e85693e1f71f@gmx.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:q3n3+jerRzDgqp4UridWeV04BoMv+vjzruV3zM+/cr59U9b8X/0 x5uyP7cOY8Xtgf28nGa4wC+z2snAe1KVKV4e1T/qjRzab5lt55oKb9O6LdcKBZN+O7OoaZB U09iacJaFa7kIctMd+cqC0Gr4MYtRUDfGNiTtERAgPl+68oZX3LGP+3a7Z5QGi+Hrf+vLTG Q4+ugo6avx+2+dWVZ3YeA== X-UI-Out-Filterresults: notjunk:1;V03:K0:E9VNZROtD7c=:pHbsigrsw29xY2LgavDv+C k/5InyfzEdmplsh1uxFHHO07u3yXsruZWvKCZ7aS8d3m2txLP027iZV1urgzrqr4fF2lmRL+U Qp/0BPmBBLRtaCtwb3INHFSzahFCuFLsQ1EcrHKJQNWWAxZgLdoiy1mQ7i5uWBVHiQINMybFb X7SQkMrYOjg/LhsD+ROvAtOJafwlXX5tYponcy24JxRQN2d7mfldXmdcWpBDBcVoyx0Jcus0E hRtGipquKgEFtcQdbdUpYScg2PTFZ+KEs1WE50yPi8xhQWMc0noY0cVQ9Qpm97YYOo1/+4tQr XrLXR5hpMQgwHJ3wuRpLW3cLQw691hOS53Lla9MPh6JjXSxXHy28NmSQTanRC17RMWqErDLlb IC019wrPz6NPRHyc5AGXsMrHSGwyndaOFhCDg1HhLyL919B/tbaRyPQLX7Xrf3TV7cCpbvdKS UTw+849m8yU7kvaewLmdh4mSoOrRqqNSmjLIqRTzAHCLuzH7LxXvonCC6yQvgedL/XT3me8Ra 3nc2gZaPbWZqsH7/EphfGfwG9S2oHrGW1KeAQSwSz/BEa7lcE6hTDhNf8G9JzZgiA6iRAti1o b91ubB0n5Q8Ke0IJ6KYZj4e5GEJEhwemZ+Zehq1KMQl8LQPQ3MFVlUDJfC59qxkVz60A+aQNk HKfflMSlZj12gYP3aKxHqPn+YAxARbOEqX+WLdMEc4gLAVn25PUMuppNAnuNUGWiavEN99gFc uFKlDo2XuXc6JGJZSTl4Roc8d73efbwqMpm8A/9SObOmK5khE0olpsh1wMwSIMwjLQlTixrYd BHj1FiwSeRpad+yzRgSd5BG5W3/ROxpkZ6MUzO4YN2G2m2WjxYgilyl44yhuv6JBpKhpgW8M1 9m34qfNDIFvajOmvyaPeIbyN2KW+eBbcVfIbb5ucK3h1q9s+uqwbGd14SGmqAQTEDmKazUJU3 CYevG+7NAmQB8p4GxW7VyMCizQtvEpiePtqt4eI8dBqra4d9O1cvnF24zJSSCaSh+6nE3FCna KQ1fjUowKy4CstCB5rw7hZHomSFh3JL2pw4C6LVUIcyz5OGoxwNEPjgRFsJC6DsVM6opWM/nD aW/i7JbfyqFXgg= Subject: Re: [PHP-DEV] NULL Coercion Consistency From: a.leathley@gmx.net (Andreas Leathley) On 14.04.22 10:10, Craig Francis wrote: > My intro says "Roughly 85% scripts do not use strict_types=3D1", and "Ro= ughly > 33% of developers use static analysis" (source of numbers noted in my > RFC)... while that does not guarantee anything, it's a fairly good > indication that most developers do not care about types (in regards to > coercion), or specifically, how you "see null as a real type". > > As an aside, I would like to include more stats (maybe WordPress install > numbers?), but I couldn't think of any which were easy to source (ref > reliability), or be that useful to the discussion. > I have never used strict_types in any code I have ever written, and I care about types and type coercions. Yet I do not like the strict_types distinction and I am glad that I do not need to use it, and I think we are not that far away from even reconciling these two systems. I do not mind that the string "5" can be passed to an int parameter, while passing the string "hello" will throw a type exception no matter what mode you use. With some adjustments to certain coercions the advantage of strict_types would be even more neglible - as you can pass "hello" to a boolean parameter without problems currently, and I don't like that. Looking at usage numbers and assuming that supports your point seems like a big leap to me. You are assuming these developers are making a choice while it seems quite possible that a lot of code has been written without thinking about all the implications, which is where so many bugs are coming from. In the last months reviewing code I noticed quite a few developers are copy-pasting code like crazy, or using generated code from other tools - both of which are often not well reasoned about. So this has little to do with developers not caring about methods of type coercions and more about the language permitting such code, leading to many follow-up problems. Also, this "problem" only affects the internal functions, yet you want to change it for all functions. If you use a framework and pass a value to a method of that framework, it would already have created a type error with null and a non-nullable argument for quite some time. I think you are making this out to be a bigger problem than it is. Sure, in a codebase with lots of custom code where no incoming variable is checked if it even exists there will be problems, but even then it is easily fixable. In a codebase based on a common framework it is much less of a problem, as you will probably be using lots of framework components and not mainly internal functions, and there you already have the "limitation" of not being able to pass null to a non-nullable method.