Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112856 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 87413 invoked from network); 12 Jan 2021 18:15:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 Jan 2021 18:15:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 269BD180503 for ; Tue, 12 Jan 2021 09:53:58 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,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.17.21]) (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 ; Tue, 12 Jan 2021 09:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1610474032; bh=MX5NSk+qEK+kGlupvij5N8yEAltOGm8gob2PRbpJ+o4=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Y6JE14MHA8tlCPupFYGxrR9IArpmZwNaoNlhZe/DhrD1G9a0v3Abg/1f4jnSfObhS tgAJKU8XQ5plirW1P4r79PUJSAiaHKPKKal5suInXef1MEQsi39qqb92s5L8wMCa3N XN0l5u4T6fnIDBnkyIBkQV209VY3RZKGyJ+WKeak= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.113] ([91.138.14.14]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MQvD5-1kcVp12QX1-00NzUN for ; Tue, 12 Jan 2021 18:53:52 +0100 To: internals@lists.php.net References: Message-ID: Date: Tue, 12 Jan 2021 18:53:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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:8lCEv8iXQNL3aG093m7w8TnubUEE03X0gb2NRQ3uDHHZWF4iVqj Dp603PHvUwN9JpRb2vF3bzlSomfSQTPs7wMQBCaSurW5ansxb/LjVi44AvqNoaUU0oe5LI3 0q+KlCyIvziAixdu5UG2qXJ4YgADoyyqH7kQ/3nRt4IzI3D9opBIQGb+R6afM8jAgg7am59 JUkamNVC6nO6+IRpxSxwA== X-UI-Out-Filterresults: notjunk:1;V03:K0:/0fYmeX6Oug=:JWDivDbxsxLos2vhvy2P3b UHeuXXpPe4gdUDk7174OrjmwAWnTjHvnMJ10i1aRBQwbSbBa22N5JAAHfb4soxDjdD06fPukS njVyJzIQsjhDUy5l7tQ7G+Snlj3myoAKAxki1Jw8UmFoE0a209/nMnvVIRLfvHUK7LsxR/gQx 1zL84WCPBHphxHUVq4ZYhjeEXIDlW3sCezsBDb0rFH6C0NQG5AbLK5F9TRhhafqM7ccd3j37z X+YjQhjZtMdWukxVnI9iPcXMmHDV4yLjaiGTjxk3czDIWhxKn/WukW+M0maPBvDhq64a0ngQF rqSqjg5cFl2R7BDdveOTo08c+IqNLWAa3QsPYAEuY5F89qyVomO6tamjkDaiMt5mu82k7GINT xdJWyPWMP/8PIVcufRUUlO4ZZAxho9nSBTYuBIrZYmIgcS4lXXnb9MWxWRvl7tAmTZGjjsNd5 XiSlX0MLygURUx//FkFKDjDy+f6va4SNbp39ODO2MuUnlZ+haSezefYxrFhl2SPv0NGTwCoPQ uBgjOh6INEbhIBPNJPpfdClhyXrbismPZleWgX7/ZqRlOtc/CaInfVyO45VpVs19R7+B8l1/Q QsQkXUk69jfJEIk2+qMHUcGq2yFy4mNYAaehiVMoNvgYWAqlz8orgMfrWJqd86T6dCRzHlLox sjeY5NeCY8NOgcePkd+Z3GAd8akrnMBEafIL2E/i7z8eEnbGjUbs+CH/PLsBOsQx287gMCYvD rLwnVkjPq+jZMsj5MmTaaJdeG4fTYpFN/YWvT09sTFRtt79wVV5cJYWr0o9jJST70zrQW1eSi rsEoAkyactd7aUEXEmYHaTQZg/wCO4Z9/hYxhNquHMOH6/G0gU6UGiUnSYfXO9QcsWAtYSVwe saijvAtxguaD4jS3M2/A== Subject: Re: [PHP-DEV] [RFC] Allow object keys in arrays From: a.leathley@gmx.net (Andreas Leathley) On 12.01.21 17:51, Marco Pivetta wrote: > Code written to deal with `array` in a generic way will no longer work > when > invoked through code paths that produce object keys: this is a general > problem with widening types overall, and is a clear BC break. If you look at levels of BC break, this is on the very low end in my opinion. No existing code will break when upgrading to this new PHP version. Only new code written specifically for that PHP version would be impacted, and frameworks/libraries could, if necessary, add additional checks without becoming incompatible with older PHP versions. It helps that currently array keys can be integers or strings, so if the key type is important, some checking is already necessary. Of course tools like Psalm would see a lot of potential issues, but those would only be potential (with new code using this new feature) and having static analyzers reduces the impact of such a BC break even more, as it becomes much easier to spot issues. Might be interesting to change array key type definitions for a few projects/libraries and see if there are that many potential issues, and what they look like.