Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117616 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 64045 invoked from network); 26 Apr 2022 11:52:35 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 Apr 2022 11:52:35 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 78F4C1804DB for ; Tue, 26 Apr 2022 06:27:50 -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.2 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 ; Tue, 26 Apr 2022 06:27:50 -0700 (PDT) Received: by mail-wm1-f53.google.com with SMTP id o12-20020a1c4d0c000000b00393fbe2973dso562944wmh.2 for ; Tue, 26 Apr 2022 06:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=n8l66kf/ULBRsDjymYZJtKLmf0vQLnE6dxpNvPPnelc=; b=Hy8jsEY3EWkr0bwDTcFf2x0MAiYRmdaG9OH1yuXLZ/p2OgLjxVyxgu4qsUwT30o8D1 sD2MPYXqiMllWAoYQJTufLmlmeiVO1InZML05+b1T+HE2B/djMNPf2qB+vtQ/0WdXWFH /hjM1Q+lhZJPP49Op2rA1qSkabcJCF5p6DxgkD+QewIAsKWWSmklRKAlXSXnzAooCs9e +4NUOm/ir0CZemm2XngLomLywSHuTY3AxXbMkVG9B05mf/NVFwS3xHA6iZ2X1yRiSive oN+aEZ3S4fI7aFyx4ayeoJlkUYGscogFobYMswe7NtgwpDULaPWJmzHP9QLTB9QFbPOW Ccsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=n8l66kf/ULBRsDjymYZJtKLmf0vQLnE6dxpNvPPnelc=; b=0r8Aq6dJ4LOGQtPDL/3Ox4INnp2/w0jmK6Z6xwCw+oLy5W0Mp7HnzDq+OnT6tc3I5s j41R4Zm4tKsG6gtqPOiUJ6SPgtE5qZj/hSt0c7gQPXLAQR8Vz/ybjryiSLflTchUdysA WLVrsLdhoXyqivOweVbAMq3RgqjNlEQQSmvPOibxtTYl/Vn7L1UHJGNhlPyKNZxykRMa C89VqAkc2Cp609rmCJXjNIS9PYTI+kmz7OP5mdeqnsUt/EKZ4ALMMdMXNsNumFx6lqLT Y9WwqnRrkr1Q+eOeHUAO0cyBdc0t3e66E7lGZRvNUAKyAxadTE+Zb3BSHgyQruxD8TJG +bYA== X-Gm-Message-State: AOAM530ZSACKgLd1rsp4mVhEdiZtDm0min7KPQ4iF7QIFsxrYCs9eNcZ 5W8XzHcSTID7VBpnPCURuRcHFnNt9vw= X-Google-Smtp-Source: ABdhPJwflDrhHquby3niwrzyxWMOPntDTtgYno4H5r+EUZS1Tz2VPbl93Hs0pdlrEmZp2gkTHZ36Ig== X-Received: by 2002:a05:600c:4f48:b0:393:ed33:4213 with SMTP id m8-20020a05600c4f4800b00393ed334213mr8164124wmq.83.1650979668060; Tue, 26 Apr 2022 06:27:48 -0700 (PDT) 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 z7-20020a7bc7c7000000b0038eaf85b0absm11040906wmk.20.2022.04.26.06.27.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Apr 2022 06:27:47 -0700 (PDT) Message-ID: Date: Tue, 26 Apr 2022 14:27:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-GB To: internals@lists.php.net References: <3fcdfa2c-7a9c-d634-ea56-8b1e5bf1a911@gmx.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Stricter implicit boolean coercions From: rowan.collins@gmail.com (Rowan Tommins) Am 26.04.2022 um 11:54 schrieb Andreas Leathley: > I have not found any past proposals or discussions to change boolean > coercions, so I would like to find out how the thoughts on internals are > to change this, or if there are any reasons not to change this that I > have not thought of. I was actually thinking about this the other day, in the context of adding new cast functions which reject more values than our current explicit casts. For integers, I can think of several levels of casts / type checks that you could theoretically define: 0) Plain type checking, no cast or coercion 1) Non-lossy casts, e.g. (string)(int)'42' === '42' 2) Unambiguous casts, e.g. (int)'42.0', (int)' 42 ' 3) Best-guess casts, e.g. (int)'99 red balloons' === 99, (int)'1e3' === 1000 4) Zero failures, e.g. (int)'hello' === 0 When I started thinking about booleans, it was much harder to define what makes sense. I've certainly seen new programmers confused that (bool)'false' is true, and having it error would usually be more helpful; but (bool)'on' being true is useful when dealing with HTML forms, for instance. On 26/04/2022 13:47, Christian Schneider wrote: > And would !empty($foo) even work in your world or how would empty() be defined? That's an interesting question; but I think it would be OK for empty() to match with an *explicit* boolean cast, and both continue to accept all values, while *implicit* casts become more strict. This is how integers already work - (int)'hello' === 0, but passing 'hello' to an int parameter is an error regardless of mode, as is 'hello' + 1 Regards, -- Rowan Tommins [IMSoP]