Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117782 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 76413 invoked from network); 24 May 2022 11:51:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 May 2022 11:51:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 04890180384 for ; Tue, 24 May 2022 06:34:12 -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=-1.9 required=5.0 tests=BAYES_00,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-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (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 ; Tue, 24 May 2022 06:34:11 -0700 (PDT) Received: by mail-vk1-f182.google.com with SMTP id bc42so8471154vkb.12 for ; Tue, 24 May 2022 06:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BZUkQcMdmuat44Ue12iylxeMIQLQQn7XsB8Klo8VATc=; b=No0sISE+GLf5JRfTwwmUcZ739y7WBUwWnBQvP/TEsl3PTZ6i+Y8xuZsJew0eb/Cg0I h1Rw+/OykkYTFHGrD0MWRGmBHQiQeTEPwmTf8dvH4y5fORvaifelwpBiwfwIOA8gy+G4 rbI/wv0nYrCDMmjtR97y/yDPFf3MwfAGAIfx7ncLSrxzMUeDTEosN2aTBc8nk2TjS+1E h0ahQbMDnJncjWK8NxZpKBY2tPh1Yc0LFpykTughImhMy41WR+sB5mCKOo+YirI8TkNP mxyPTJQBFmz2tNUO7ygRgiaE02zjR/keRt69vm6pQ1F1e0grrviPQp/fWr3U3UdYLYhC hLFg== 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:content-transfer-encoding; bh=BZUkQcMdmuat44Ue12iylxeMIQLQQn7XsB8Klo8VATc=; b=fuUBR6xOkhFB3Uqt+rzK7QCLI2vDUhSnDII8UhEg4B7RwlX6CSfqJUKGYx1XlCDdfv KMr2UYsiqvCgOeEnyAY4sfAj2zry0cn5D6aNmSQtpZnRJIlkyZfJ9uosRFDkU/xpmcoH tvr1o8+gj6u8yM0KSl5vb338ImAaCsyxpa4mZCTVRAe6Ny7bZ1OAhCF78vk//G1xNU5H 7h/Tp/zC/8+YJTxrBinjyHH1RZf/Bhyv4w327TO3gtrgqrYp+tIV9gJ5CA+u5UaW4W0d ntM6bV0Wo//J6SiBYozDFxg/6NEieW85Ivs0zbQJ5IiJwbxIZMC0zPph1TCtJ6THXEqT VzQQ== X-Gm-Message-State: AOAM530VBi2hao65V5kyAhDH1H5hKpZnRDufzgC3Q7/XxsfHD/EoTC/3 42G11GLJPRY8/yCHfYqwZsyn8/FWj9TZSNViPA9AULO70rK1OQ== X-Google-Smtp-Source: ABdhPJynjrREb/yxEuURZxxh8WyL3Y07D8AQRO6u5g5s+4qn4AM1C8rLXB2dr+H/2Cp6gCnFiSalg1wdffR9Stec09o= X-Received: by 2002:a1f:a44a:0:b0:357:41e2:9199 with SMTP id n71-20020a1fa44a000000b0035741e29199mr8961059vke.9.1653399250966; Tue, 24 May 2022 06:34:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 24 May 2022 14:33:58 +0100 Message-ID: To: Andreas Leathley Cc: internals@lists.php.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions From: Danack@basereality.com (Dan Ackroyd) On Mon, 16 May 2022 at 16:06, Andreas Leathley wrote: > 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. "When discussion ends, and a minimum period of two weeks has passed" Fyi, the two weeks is a minimum, and almost certainly not enough time for subtle BC breaking RFCs like this. > I appreciate your feedback, and if I can improve anything about the RFC I think you should really explicitly list what the changes are in a single table rather than in sentences. > Would you want to know when a value like -375, =E2=80=9Cfalse=E2=80=9D or= NaN > is given to a typed boolean (and coerced to true) in a codebase? Yes. Which is why I always use both PHPStan and Psalm to detect those types of things where those types of bugs are important. Also, strict mode is great. > In one application recently I actually had the string "false" (coming > from a form transmission) being passed to a boolean argument and leading > to true, which definitely was unintended. But "false" is a perfectly sensible thing to pass as a string in an API (as HTTP is a string based protocol). As is 'faux' if your API is used by French speaking programmers. You need an layer of code that converts from strings to the precise types your API needs, rather than just passing values straight through. > if it mainly reveals bugs in applications, couldn't that > be enough of a reason in favor of it? Although this change would probably detect some bugs, it's not at all obvious that the amount of pain would be worth it. A lot of applications out there aren't being constantly developed. Instead they are in maintenance mode, where there isn't a programmer dedicated to constantly work on it. There would be lots of function calls to check, and some of them would need code to be modified to maintain the existing behaviour. And all of that would seem to be subtle work, prone to mistakes. cheers Dan Ack