Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110852 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 82704 invoked from network); 6 Jul 2020 20:52:59 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 6 Jul 2020 20:52:59 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 96D79180503 for ; Mon, 6 Jul 2020 12:43:28 -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_H2,SPF_HELO_NONE,SPF_PASS 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-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (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 ; Mon, 6 Jul 2020 12:43:28 -0700 (PDT) Received: by mail-lj1-f194.google.com with SMTP id e8so12670954ljb.0 for ; Mon, 06 Jul 2020 12:43:27 -0700 (PDT) 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; bh=/tiSulUHerg5VRXGMy4xzGSj9NfugN+k8xWDjfn/CTY=; b=Xz5zu9lT63v8BtTCkoAb0QEWtfpy5f+RNnmdkw8lXyxuQsfuhK6geoGXA3x/8y79YJ OMNibqd5UpPaYHRrP1T9ATbUHRKwuoImY3Gl9RnT70bdtXCE5o4HSGWCWh+5tO8ui7ju /7L7haeijCrRzzkp2xitT1BNPER1B3mzFYD7K2Cb8aT5+W9qoxGWCOsLPPMOa2PFBDYb aQcZ/ZXfEJ8VSb9a5OJRaPbceuQKe33nVTaXz8pnrQ1fjMWpVggncK3wQZGS3LG1QPbq OZ+UvNkh8G2kK4I/Kd2ukFYTi2jV+2KMbk7GAjDWRriaxuoJ8lMtwcc+pQEUQADftnab ihvQ== 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; bh=/tiSulUHerg5VRXGMy4xzGSj9NfugN+k8xWDjfn/CTY=; b=LELBOsQrLjikPmCP7XVbUMVQkajPTXcdkbVyBRzgFYMj1r07fw13rBx3wihXC81OrR TOjqL9RKpuvO0wk/hK6YaDVILNS4L+sDo9hWD5MpL+qn7lWvvCWkvmFNiTzMXKj4r3fv Lb1TAEQ8swsQE9bekPsxsIthBODXZph9dogOtaAF0xvz23bQY/Ai2kT2zUNfz8I5zp4L B1jB9iDJSDVxHcaaSxyYra3gYQktODBgkubZN5zfZlAjuuStxfFChvoKbZNxLCRfrgIA gmKpjJfsvAr0D32oZ4szlw5IYEZF9pY3lryGLI8/LuT3lt5nZUkpsI7m69wc8JfsFE6D IoTw== X-Gm-Message-State: AOAM533+lvb30mDVpjGYYsjbtVYghT2FVKOUD7blyfbESQlgeJZKbOGK XzNR6SfDgNlkpePZtVapQg9w1at4N7fOHx/POEtYgGHZ/Cg= X-Google-Smtp-Source: ABdhPJyFt+OTyfLlTTiYH4+dy8bB8j7BTpKu9bhRa/eOXwjrD+pnTNBwDpeYx2Gkd+DMXz85T08Qy1O1t9g8MT/rIh8= X-Received: by 2002:a2e:9eca:: with SMTP id h10mr29181388ljk.273.1594064602857; Mon, 06 Jul 2020 12:43:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 6 Jul 2020 21:43:11 +0200 Message-ID: To: PHP Internals List Content-Type: multipart/alternative; boundary="00000000000067091f05a9cb1605" Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Strict operators directive From: arnold.adaniels.nl@gmail.com (Arnold Daniels) --00000000000067091f05a9cb1605 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 6, 2020 at 6:22 PM Marco Pivetta wrote: > Hey Arnold, > > Perhaps it makes sense for <=> to still operate with other types, as long > as they are uniform? Specifically: > > * error: 1 <=> "1" > * ok: "a" <=> "b" > * ok: true <=> false > Using `==`, `!=`, and `<=>` with string operands can lead to unexpected results because the operation differs when both operands are numeric strings. Instead `strcmp` or `Collator::compare()` should be used. See https://wiki.php.net/rfc/strict_operators#numeric_string_comparison Boolean operands could be allowed but that has limited use. Only allowing int or float is much clearer. > Similar for sorting: I use <=> to differentiate multi-dimensional arrays: > perhaps it should error if the array structure differs? > Some functionality concerning comparing objects and arrays is lost with strict_operators unfortunately. The RFC reduces complexity by throwing an error purely based on the type of operands and not based on the value of the operands. Alternatives where `==` and `!=` are supported for all types, are as complex as the comparison rules without strict_operators and/or result in cases where the outcome of an operation is changed based on the directive. > The rest of the proposal makes a lot of sense to me. > Thanks. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > > On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels < > arnold.adaniels.nl@gmail.com> wrote: > >> Hi all, >> >> I'd like to start the discussion of the "Strict operators directive" RFC >> version 1.5. This RFC proposes a new directive strict_operators, which >> limits the type juggling done by operators to avoid unexpected results. >> >> https://wiki.php.net/rfc/strict_operators >> >> There are some significant changes from the previous version. >> strict_operators no longer has cases where it changes the outcome of an >> operation. To achieve this the following changes are made to the RFC >> >> * All comparison operators, besides `===` and `!==`, only accept `int` >> and `float` operands. For any other type a `TypeError` is thrown. This >> includes `==` and `!=`. >> * The `switch` statement is not affected. >> >> For frequently asked questions please see >> https://wiki.php.net/rfc/strict_operators/faq. >> >> [Arnold Daniels - Chat @ Spike]( >> https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=l1bam) >> [l1bam] > > --00000000000067091f05a9cb1605--