Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120234 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60653 invoked from network); 11 May 2023 16:58:39 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 May 2023 16:58:39 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 29341180382 for ; Thu, 11 May 2023 09:58:39 -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=-0.5 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 11 May 2023 09:58:38 -0700 (PDT) Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-965cc5170bdso1320012266b.2 for ; Thu, 11 May 2023 09:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20221208.gappssmtp.com; s=20221208; t=1683824317; x=1686416317; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=eeygazzkf0HUsTafixg0Gt4A10Hx3pN1d99U+5z30+0=; b=P7aw1+idwi6KB24AeW/Hdbi7VaipHf4dkoJ2Ambl0PgY6o+Gku2x63nl7tCagfiifw mtXupqQgfEnQq+qEqYD/6qPCRPeWjLves0PfLkSPSuldOwiyFmpchB9n+TPjgf0dK/R+ 0XACGXfJ2tVYtD1P7DwmWuYQK6VkDg94YB2FIXlTgDl0Sterz+tnaQi1s4KgX8WTaOJB seItN0ohOsm6zhlrCoxDcs2qWsyzHlVOH8dcHeEgSJLyPhY5T21SOUgfAdLq0WYngalT OHPXjxO6Fy5YEbYGRCXBGkx6q1QXH7MfO1rh7IddA+wtMUEJGOkvV48LOOWiYIjFt0vG 430Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683824317; x=1686416317; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eeygazzkf0HUsTafixg0Gt4A10Hx3pN1d99U+5z30+0=; b=SC2lQ34OON/gCOJ06Q9bq6me6wPlUXlVx5wkDR47jnHlVM9EmbDBEous653yd1KYHt oWwzplCiPWdvkGO91t4hxRfNyIbsmxDlpYJauzwGXDss+DYzpFwnsaUSVwKe9Q2TvdUP a0ykBrfRXFQQydWw9YUF+C970+HwlZAZYD06UsZWl/Kl51x/Nr6cRXS0YleQC2EtP3ZU DwScHQpflR6HP6IE3DcDwNA9PqXttv8y5n2PV+nf8UJq1fxg6eh+a7fvQ+0QtHKC/tIP m5qnvle2gXldAjmtRVHkPuB3Rw09nXp1Z2UOeClw10dWchIX5n2FAc5WTH68w7M88Wzh V30g== X-Gm-Message-State: AC+VfDwaHM83L5MDnl43kEesSreMxkGVAoxt/C+EDOjgA7MVB/ikXNET kD5kdSA1kvqPo6wMAkAUFcH3BLhGXKq+q+rEhFIwJg== X-Google-Smtp-Source: ACHHUZ6qlhqN/VZcjyPkYWwLxyP16C0FpySzgfu3qzmjP9RVh7LJvvIU4Gnj6wqqEN3P/0YnmZSQ0ZwRrcawhqUS8JY= X-Received: by 2002:a17:907:7dab:b0:96a:4f89:3916 with SMTP id oz43-20020a1709077dab00b0096a4f893916mr3491130ejc.58.1683824317027; Thu, 11 May 2023 09:58:37 -0700 (PDT) MIME-Version: 1.0 References: <9ab0173f-a6f2-66f6-3ab3-d5f0c44feb05@bastelstu.be> In-Reply-To: <9ab0173f-a6f2-66f6-3ab3-d5f0c44feb05@bastelstu.be> Date: Thu, 11 May 2023 17:58:26 +0100 Message-ID: To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= Cc: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= , Larry Garfield , php internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures From: Danack@basereality.com (Dan Ackroyd) On Thu, 11 May 2023 at 10:36, Tim D=C3=BCsterhus wrote: > > Would it be an option to just deprecate everything in PHP 8.3 As I said before, having at least one version where the new versions of the functions are available, and the old versions aren't giving deprecation notices, is the 'cleanest' way of refactoring functions. Deprecation notices only deliver their value when the old versions of the functions are removed, and before then are a cost. > It doesn't really feel right to decide on > a deprecation for 9.0 / removal for 10.0 at the current time, but > deprecation in 8.3 + removal when it's ready seems to be okay. I think I don't understand your concern. If a problem is discovered with a planned removal of something, people on this project are mostly reasonable*, and a small RFC to adjust to the new circumstances would be very likely to pass. cheers Dan Ack * though sometimes they base their decisions on experiences/value different from my own, which makes it not feel like that.