Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112854 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 81117 invoked from network); 12 Jan 2021 17:13:38 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 Jan 2021 17:13:38 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B38D31804D1 for ; Tue, 12 Jan 2021 08:51:38 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (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 08:51:38 -0800 (PST) Received: by mail-io1-f53.google.com with SMTP id 81so5402440ioc.13 for ; Tue, 12 Jan 2021 08:51:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xDCRAFgSS3WMeQDevsmHpfOb1Zwa9pTlUC1cWt0XYl4=; b=II2VUsYDv5K6P3g2ZOPqu+0d2oqtH0WY4nSiRCnl6nPX6hCNbGA36pBNpb6Oitm4R4 gDQE1dTgVwyEgWsduDx1U000drcM8+6VxGim0396p//g6F+91mIFDfr7fHoMMxWpArj3 xWinHk4LhCWHhs//llmNggbgP+MFvvI0rd5vcAzD6yK6VILtRGLh/P77CSAPNZqH7Hra 8duS5EmyZ/lO7ykURom05AyDqid3fgpUNtQg8xsGcI4JJkBpAie3JvG0ggxvgYWhPdO+ l5Qd7H8jgThYARXT99CeTV2xmOEx9hbbxnCmlk3s5X94seyXO6o8kVOj8jRn0nfbF59I X7ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xDCRAFgSS3WMeQDevsmHpfOb1Zwa9pTlUC1cWt0XYl4=; b=UoRInf4eRY7piG3qjQgGv8PLd71sZMBa6IEphgnnuWz87ju5jS5pkZzXUg25gnriip K/VFI7CeeH/XzuwvDc6LPv1nPoXUX0zWIg+68+L68nQNUEVqk4UztgK9vENEOY734+aP oimteRMRghBNMQZ/5mFegLsji0JbFqVKeJpUtLv2/3rnvqQQ5W4k7N6kXVj8yxOmoRU5 DnIR6pk+iGWAy6K9cQweRoXAwgen6b5DKPPiWhDzOD+Q1FCQ5UWOROWiarCK7iOPmwKe YRVfEVnqhymIBitnL6EIR9f1qMMjvtCMcJKu1Qwx6Ze8/9ZWS+MkkcajO5NNLPux7qlJ z8zw== X-Gm-Message-State: AOAM531ylT+6Hqx2AYFT2jsUAhY1Kc6eHnoIfdAMNCLOAxjbSJXichjv J8zOj8o1tKX55xd4IFXB1zcNiWcRZc/nUYxEajY= X-Google-Smtp-Source: ABdhPJxYiDsa/yu75NXj/Pfqmj21xvSdoj4UpvQdlCbU34Wu2mL5RjS9I7dXzYMlhLJMZJL3thYGYXIg/VSGz8tHZ9c= X-Received: by 2002:a02:c7d1:: with SMTP id s17mr232803jao.142.1610470295873; Tue, 12 Jan 2021 08:51:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 12 Jan 2021 17:51:22 +0100 Message-ID: To: Ilija Tovilo Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000e82ef405b8b6d509" Subject: Re: [PHP-DEV] [RFC] Allow object keys in arrays From: ocramius@gmail.com (Marco Pivetta) --000000000000e82ef405b8b6d509 Content-Type: text/plain; charset="UTF-8" Hey Ilija, On Tue, Jan 12, 2021, 17:35 Ilija Tovilo wrote: > > Definitely disagree here. Your existing code will continue to work fine > without changes. > 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. This can be verified by expanding the `array-key` meta-type in tools like `vimeo/psalm` to include `object`, then scanning for issues in existing libraries. For example, on generic arrays it was safe to cast keys to `string`, but that guarantee no longer holds true, and depends on caller-side values, which will change with the new addition. So yes, there needs to be a code migration/adaptation in a large number of downstream infrastructural libraries. Again: this is a common problem with widening types (function return types, operator/constructs possible return types), and hence why I bring it up. Whether the problem can be mitigated is what should be discussed, but the problem is objectively there. > --000000000000e82ef405b8b6d509--