Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112910 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 34063 invoked from network); 16 Jan 2021 19:22:39 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jan 2021 19:22:39 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A1BDB1804C6 for ; Sat, 16 Jan 2021 11:01: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=-0.2 required=5.0 tests=BAYES_20,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-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (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 ; Sat, 16 Jan 2021 11:01:38 -0800 (PST) Received: by mail-lj1-f170.google.com with SMTP id w26so13998934ljo.4 for ; Sat, 16 Jan 2021 11:01: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=4gfqPDSRKu2qv+H6RHe+/inStfLhmbyr8AAlvEjugkw=; b=ciDTLnhpV0y2WcAbQA0trWh+jsSnYbWSOzEJsUqRnJZazD9aLFs3lhMQZLmS28StjV f8A/boey/Q87dA87i9X8rc49/YyAKk17YeF4iFOk0r8h+jrOGnghDN5WLxCfESPcxjk+ VOK2VMxQ4vFk7n82lToFaTiPkapbE8vOuHmiEflICK8kUKJrYSXnCvxL2MYpRGReeMh3 aYAK/7fjFNZ+QNc+ZX0ySLM4lMtTekcUGmADdGFibdPe9WSY+MH0hq+RVqCKR5yhc0Et uoa8OOjLr90pUTLS4v1u6kkFQG+2cax51y1BbRNeV+HVA93pbTMScKL6TyOM+9o4OjFi WTTg== 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=4gfqPDSRKu2qv+H6RHe+/inStfLhmbyr8AAlvEjugkw=; b=WLIHArNY+i0zmpZC8t8xDJg2taOvD417yz433QmXczZqKVEONBhAIKqjxPmZoVhqcQ +srgIYe+dJDc1bxSnFE+hNmH5c3S3e/jnk6f+ZxuiBgKDYx6yW0xmN1e+ZNpxP388iLF bX6SdgUaLSd9Mt3hkBAXZ6nFvEBudHpogeUQ9772jbvh+7GNp//FgtYEMF5bNIVaxkSN Q3no2w2ATSoYgulqWFpkCB6UCoPLDxsGjB0njLmgESrL3Ac/tNS2kcTUs+qhzy0dBtkV IaGSGROXcXJhHsxq1mcfqobxAVkFcfj0PB46BBLNcjXgmK4bI9l936tVN8/+LZTLNbU/ VWqg== X-Gm-Message-State: AOAM532j3q26h0cMgpczVxwGOs6yJ6gr4D7/6pyAPlXu3bsqr7nt0dh3 EVRB8SNM/8uX5cSsfalv21KuKPzCrkIFrZQ+YPC5JhBFzZsOMA== X-Google-Smtp-Source: ABdhPJxq8clWP8dWkcVgtBDC+VOwzEmwvkmSUb1Ndx1FMj0HDRMuQT6sbeue33Le/KQQ8nkC0I7PVP0lToQifY/GfWE= X-Received: by 2002:a2e:2284:: with SMTP id i126mr7935691lji.93.1610823696493; Sat, 16 Jan 2021 11:01:36 -0800 (PST) MIME-Version: 1.0 References: <70E24D44-D791-4AEB-92C3-3B8C9579F5CC@cschneid.com> In-Reply-To: <70E24D44-D791-4AEB-92C3-3B8C9579F5CC@cschneid.com> Date: Sat, 16 Jan 2021 20:01:20 +0100 Message-ID: To: Christian Schneider Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000039b1ad05b9091e51" Subject: Re: [PHP-DEV] Consistent type errors for internal functions and BC breaks From: nikita.ppv@gmail.com (Nikita Popov) --00000000000039b1ad05b9091e51 Content-Type: text/plain; charset="UTF-8" On Sat, Jan 16, 2021 at 6:07 PM Christian Schneider wrote: > While testing the migration of our site to PHP 8 we noticed the BC break > in internal functions like round() for parameter type errors: > round("foo") used to (silently, without warning) cast to float and return > 0 where as now it throws a TypeError: round(): > https://3v4l.org/pU0LD > > The RFC at > https://wiki.php.net/rfc/consistent_type_errors#backward_incompatible_changes > states > > Backward Incompatible Changes > > > > A TypeError will be thrown instead of a warning if incorrectly typed > parameters are passed to a function, which is a backwards incompatible > change. > > But that is not the whole truth because it suggests that there was a > warning in 7.4 which is not the case for functions like round() and > possibly many more. > > This makes the BC break much more impactful as there is no easy way to > know if old code will suddenly abort with an exception whereas it used to > run without any warning. > > Is there any way of knowing what functions are affected by this? > > This might be a blocker for people to migrate to PHP 8, should there be a > way to have a warning-instead-of-exception stage added to PHP 8 even though > there first versions were already released to help people migrate? > > Or did I miss something? > This is the interaction of two changes. The RFC does exactly what it says, and promotes certain warnings to Error exceptions. At the same time, PHP 8 moved some function implementations to use standardized parameter handling. These two changes in conjunction can, in rare cases, conspire to produce an Error where previously no warning was thrown. round() is an example of where this happened. I don't think there's a comprehensive list of edge cases where something like this has occurred. It would certainly be useful if any cases that are found make their way into the manual. Relevant changelog entries are being added to functions as their methodsynopses are updated for PHP 8 -- this is ongoing work and has not reached the round() function yet. (You can find all changelog entries for PHP 8.0.0 that are currently available on https://www.php.net/manual/en/doc.changelog.php, though this has more information than is probably relevant to you. Many of those changes aren't backwards-incompatible, just document previous behavior.) Regards, Nikita --00000000000039b1ad05b9091e51--