Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117783 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 79218 invoked from network); 24 May 2022 12:17:29 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 May 2022 12:17:29 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EA90C180083 for ; Tue, 24 May 2022 06:59:44 -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.7 required=5.0 tests=BAYES_40,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS8412 83.65.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from mail02.x-net.at (mail02.x-net.at [83.65.141.138]) (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:59:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail02.x-net.at (Postfix) with ESMTP id 5B5E13804E8; Tue, 24 May 2022 15:59:42 +0200 (CEST) Received: from mail02.x-net.at ([127.0.0.1]) by localhost (mail02.x-net.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id rav0-2S8rq9M; Tue, 24 May 2022 15:59:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail02.x-net.at (Postfix) with ESMTP id 1DFCC38051E; Tue, 24 May 2022 15:59:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at x-t.at Received: from mail02.x-net.at ([127.0.0.1]) by localhost (mail02.x-net.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AWaS_V6WG-XD; Tue, 24 May 2022 15:59:42 +0200 (CEST) Received: from [127.0.0.1] (213-147-166-73.nat.highway.webapn.at [213.147.166.73]) by mail02.x-net.at (Postfix) with ESMTPSA id CD720380533; Tue, 24 May 2022 15:59:41 +0200 (CEST) Date: Tue, 24 May 2022 15:59:40 +0200 To: internals@lists.php.net, Dan Ackroyd , Andreas Leathley User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions From: mel@dafert.at (Mel Dafert) >> In one application recently I actually had the string "false" (coming >> from a form transmission) being passed to a boolean argument and leadin= g >> to true, which definitely was unintended=2E > >But "false" is a perfectly sensible thing to pass as a string in an >API (as HTTP is a string based protocol)=2E As is 'faux' if your API is >used by French speaking programmers=2E > >You need an layer of code that converts from strings to the precise >types your API needs, rather than just passing values straight >through=2E In my opinion, this is a good point in the RFC's favour, as the depreciati= on warning will show up in exactly those places where this conversion layer was erroneously missing=2E