Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117777 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 22014 invoked from network); 23 May 2022 19:13:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 May 2022 19:13:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EFC0C180504 for ; Mon, 23 May 2022 13:55:03 -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=-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_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS,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-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (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 ; Mon, 23 May 2022 13:55:00 -0700 (PDT) Received: by mail-ej1-f49.google.com with SMTP id y13so30597936eje.2 for ; Mon, 23 May 2022 13:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sn+Dp/YxBzUlcEibLls8R60sihl/NChsmCjAKPWgW44=; b=QGkFJhfJWXVn206S8BnpNHTaU11te0QJt4q20xry8MsTMgTHlEwOLUurqQoxseD9wE izaJYU4nLhpTMLPs7GTbxTAD87wMaSuFCnbiz2Cl2lgJqekXQEGU/PeemXhRyl6BzEkj gIrkYjCXINtFQNi1xF4BllAI1fFboWGfxgByrTIk+aSWGyWaZXouMU+8BEsP7vlk+UtT 9WGtFym/CRQUshqc+dVMgyzBx378zinQ4Rf5LxVZZt0640XNazdoU28UEgFs964AWwSf fJWy91DSrTcLBX0BQ3LfRdco4e14kVtuNQZg0zBpeb4O47O+hVR4g4U3mI1ke386SYA+ pO8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Sn+Dp/YxBzUlcEibLls8R60sihl/NChsmCjAKPWgW44=; b=A4y8R+pCrMdzMa2ViZUoM8buY74Z5wAGPlvok/sEnvsQVphzL3rAymUzPOkguI4+yy CociA++Ln+0CGz9Cq7kmFUiqrf9GiIULoNlSr3MVlwhyu3mN409uda675IPFcOAB96Xx qcZpqgNXO+GRe9mwsV90a8pdHMhUHRjY497hMQ87EIoP3WGMjE7xlXdkKUEUFQnjBeCP lMlEuZBw4vX3SqtS7oyPsZ1ClbCGjnxMdDs7xmLrs6YN6bMmsU9e5z2Xld+A9xjb5n66 6FR6BJdsz0ARcLhjFqSNugQbzt8fMerMCJCsCvGhplAlGpYToF5yTFUZvK5DSW91rILQ JZTQ== X-Gm-Message-State: AOAM5328h0oh0dH6nRQS24jgvN/tcR/U7Zv2vg72EFtoqRzpnQfM3ROz Fo6v7RZ5hTAuJViZBbfvVl5SA8p1JB25v4ujpTk= X-Google-Smtp-Source: ABdhPJyTG6sCwV8uPFudNkqztVa2p1DKxIif8UbIai9hoD1pBggY2phye5Si9Q+TH9yN2XgUmOQ6ru/clREGhh9GdP0= X-Received: by 2002:a17:907:968e:b0:6f4:d80f:f0c3 with SMTP id hd14-20020a170907968e00b006f4d80ff0c3mr20456925ejc.145.1653339298963; Mon, 23 May 2022 13:54:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 23 May 2022 21:54:46 +0100 Message-ID: To: Andreas Leathley Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000009ba56005dfb40dff" Subject: Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions From: george.banyard@gmail.com ("G. P. B.") --0000000000009ba56005dfb40dff Content-Type: text/plain; charset="UTF-8" On Mon, 16 May 2022 at 16:06, Andreas Leathley wrote: > Hello Internals, > > After the first discussion about this topic > (https://externals.io/message/117608) I have created a preliminary > implementation and an RFC for making implicit boolean type coercions > more strict: > > https://wiki.php.net/rfc/stricter_implicit_boolean_coercions > > With this email I'm starting the two week discussion period. I welcome > any feedback on it and hope to further iron out the implementation if > needed. I mainly chose the route of introducing a deprecation notice > because it is in line with other RFCs that have similar goals (like the > Deprecate implicit non-integer-compatible float to int conversions RFC), > and it is fairly non-intrusive. > > Best regards, > > Andreas > I'll echo Juliette's comments. I don't like this RFC as it introduces special coercion semantics for boolean *only* in a function (+ typed properties (well at least I hope it impacts typed properties)) context. The obvious other context is the logical one with conditional statements and/or boolean operators (&&, ||, etc.) where it is pretty typical to do if ($string) {} and use $string as a boolean value. Having this be true in some contexts and false in others, depending on the content of the string is far from ideal. However, implicit coercion to bool can also arise when doing comparisons where one of the operands is null or bool. In this case which semantics should be used? The proposed behaviour is in stark contrast to the one I brought forward with the implicit float to int coersions. As this deprecation occurs in *all* instances (moduli explicit casts). This is also the reason why we stopped pursuing the deprecating implicit bool to string RFC as using a boolean value within string interpolation/echoing is somewhat common and would not reduce the cognitive burden as one would need to remember yet another case about implicit coercions. Even the Coercive types for Function arguments RFC [1] which went further in differentiating function scalar types declaration and what values would be accepted did not include such a restriction for bool type declaration. Where it does propose something somewhat sensible by deprecating float to bool coercions altogether as comparing equality for floats is far from ideal due to approximation errors. Can this prevent bugs, for sure, but within the function context we already have a tool to deal with these sorts of issues with strict_types. Best regards, George P. Banyard [1] https://wiki.php.net/rfc/coercive_sth --0000000000009ba56005dfb40dff--