Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112871 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 90240 invoked from network); 13 Jan 2021 14:24:04 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Jan 2021 14:24:04 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 475931804F4 for ; Wed, 13 Jan 2021 06:02:17 -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, 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-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 ; Wed, 13 Jan 2021 06:02:16 -0800 (PST) Received: by mail-wr1-f51.google.com with SMTP id q18so2259421wrn.1 for ; Wed, 13 Jan 2021 06:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=GaDXj+td9O4IxuXJWRLliwnsCp0oGrCxDpXrOZXO8BA=; b=RvXWe+gdMc/txhkFoJ+xZVEh0c3/pSp6Nx7Ei/0gRb7MkdGQZBxPjhUgeXQqpzJvfw OQwf0JLrRv5Y5BPNhysx05Wdzqp0FySEksJP2LFOPaxC6pp4nb7RwK962bWDRTNjRsfE i5apANne/WgMxHINBoXWmmW0GRO0FJX4Ffq9EnvNcHGf02OnW3ZEaklGtG8au9QHErRa zgX12i9ru/43aVYt+3bWABJn7PMuss900mGDk+o0cW0JUBErf6LBO4o1YQIIHLIoz+BJ kEEZ8hdGXpTbsS9HEMc+GlXXpRtt+b+9gtuN6nnzdpNAYczsa+oPgRP43YR7gd/CDnIH S99Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=GaDXj+td9O4IxuXJWRLliwnsCp0oGrCxDpXrOZXO8BA=; b=LUkIQat3uv3OKeKj047db+6/OF7Srfo5NiL8WiipMzrGZQydzfJmDxHrJwf2GwPXfY GPrrCsGSOk27Oym6lbaqFr1seXOZRInhwOfjyzfvFceOM9ZqgvLy94TPkq5QCIpXcyI5 Y39KZY9huffO0pKvT9GtHEK8ymypurRl7ACzYD+9IU18gK4eNdhcnnJtJxHQUpFCtTon 2iFNB2VNM5f0G2dstycM55GPxD4ZJ69YaeAbjUgy58TG6Byw6wS9gQwGiYCyDAggEo/Z NrIjxgJum44KOBIADbBFZPhkWCrLvhd+8/rF9oG3zG4tMJEn88UfTDvuX5O/xGA1b77z zzyA== X-Gm-Message-State: AOAM530lREGborA9V/4N8whZ4NsH1HtYV/suS6giE2qsNc1doSoE/ZDI Lz986FWTlwE8jFzdfrCPXxHTvm9RJjA= X-Google-Smtp-Source: ABdhPJwh6SzTCAumTovUpDKC5V50fBU49/txKOjXMsO6KUzeMPgRAX0aeVXY3DcJ99ifZt3T99RrGQ== X-Received: by 2002:a5d:6983:: with SMTP id g3mr2808836wru.168.1610546535322; Wed, 13 Jan 2021 06:02:15 -0800 (PST) Received: from [192.168.0.22] (cpc104104-brig22-2-0-cust548.3-3.cable.virginm.net. [82.10.58.37]) by smtp.googlemail.com with ESMTPSA id n11sm3940596wra.9.2021.01.13.06.02.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Jan 2021 06:02:13 -0800 (PST) To: internals@lists.php.net References: Message-ID: <7755901f-d9dc-2a59-c0f1-6076599b676d@gmail.com> Date: Wed, 13 Jan 2021 14:02:10 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Subject: Re: [PHP-DEV] #[Deprecated] Attribute From: rowan.collins@gmail.com (Rowan Tommins) On 13/01/2021 12:51, Marco Pivetta wrote: > For me, runtime behavior is: > > [...] > * a production outage risk If your production code can cause outages based on E_DEPRECATED notices, then that's a bug in your code. I can't think of any justification for a production system to abort because of a notification about future changes. If we have to consider every introduction of a deprecation notice as a breaking change, then we're stuck in a Catch-22, because the whole point of such notices is to warn of upcoming breaking changes. > As usual, I'm fighting for pushing things into compile-time rather than > runtime In principle, I do agree with this, but as Benjamin says, it's quite a meaty topic in its own right. It's also unlikely to ever eliminate 100% of runtime checks, because you can't statically analyse completely dynamic code. Defining #[Deprecated] as "do what all the other deprecations do", and later changing that *for all existing deprecations* seems reasonable. Regards, -- Rowan Tommins [IMSoP]