Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116769 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 55872 invoked from network); 3 Jan 2022 00:36:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Jan 2022 00:36:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 355B91804C3 for ; Sun, 2 Jan 2022 17:43:46 -0800 (PST) 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-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (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 ; Sun, 2 Jan 2022 17:43:45 -0800 (PST) Received: by mail-lf1-f48.google.com with SMTP id i31so72033885lfv.10 for ; Sun, 02 Jan 2022 17:43:45 -0800 (PST) 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=0cphn/JWtefoMh3OHTs/lPb5gaqmNh/Chce9eUT4CWw=; b=Vof4CxX9itwRqBsPXWviXZTGTIcTzV8LRfRuR60Gf18V5Ft1fJ1/rmpvO2AUMcY8p7 uG+uUUQyxF6/qPkhORKpDpWSmlUOzSlNzmLFLTfgmmxTUnnc0Za83TsMxN4fI+0o7+GP zXWUYiIWBXCtNJFrTaxM1DtPRd0W34bzEKNt/XRDriDg1N0DMS3XS/P0kvxLmKcqfJOj ciIyEuMRlHs2Soa6bUuuXrT17qP8q/KUpwUv9/Vo65948vcdbSVqFq82BZCPp86c6rG4 Xfw4//ipYbxKkykc6JMklgXnVMQY9IKcuX2jC7Xbfe/8bRcJcEDe9FEE4ztkHfGBhWDD 6PFQ== 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=0cphn/JWtefoMh3OHTs/lPb5gaqmNh/Chce9eUT4CWw=; b=JpYMIUujg9rAI53EoUxT4UPtWE9NqK3zZyjmw68IJBvL0NP7E6YzvdI9da+StlL3oe u+j/FqeMeL+a+Hbwtmi6PazWnnfFJgdzEiSG9LR5Mlvh+Cp9K5pxQ1zJs4oIPfT7d8Zu uT6BmER2FSB6OQAquaL2dDKvJN6UEveIbeFdkyhTkyTPoPm7BUUhX5w+l3Pwh0OSsmZC 2XxCKcnxH/8KA4YJr3Kr0rMTbCtOyY3TSv4NOs/62FAwBjoZ+0LybX5EaRwNZ4gu6th+ Xc53yEcGtJfI0X9q1rsrmKwA1CHnvbeRav/fK6S7EBijnUnAEoc+EzA84JadiCvT+xBh cTHw== X-Gm-Message-State: AOAM532zgNZV1rGcrNxJwyuGvOyeTfI63HkssFGPgGJl0N7+0kKs4Lfa NdhkoGAARw1DtCPAnvuDVcWa9wpQ2i0IJ/b2BEg= X-Google-Smtp-Source: ABdhPJwX2BFlrZj1R+AXocLj9M9mcIhFcNIMRz0jfUCBhu9zEPzFliVwV37Y7+FaFFeP/nTm+5B1A+iUC6WrSOhffbE= X-Received: by 2002:a05:6512:2116:: with SMTP id q22mr38993418lfr.258.1641174224071; Sun, 02 Jan 2022 17:43:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Sun, 2 Jan 2022 17:43:33 -0800 Message-ID: To: Marco Pivetta Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000a3ef8405d4a3a609" Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads From: jordan.ledoux@gmail.com (Jordan LeDoux) --000000000000a3ef8405d4a3a609 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 2, 2022 at 5:07 PM Marco Pivetta wrote: > Hey Jordan, > > I've voted "no" on this one: infix functions may have been interesting, > but adding a whole new type system around operators is really not worth it, > given: > > * Added AST nodes > * Added method definitions for niche use-cases > * Complexity in support for static analysis tools > > I personally don't see a reason to introduce all this for examples like > the one with GMP, which was more readable before adopting userland custom > operators. > > In addition to all that, we didn't even achieve custom operators anyway: > it's just the built-in ones (this is why I mentioned infix functions), and > the precedence, number and type of operands are fixed too (yes, it is a > sensible starting choice, but very little "custom" about it). > > Overall, your RFC is exactly what I would expect a custom operator RFC for > PHP to look like: I just don't think the feature is needed at all, as it > only makes the language much more complex, for rare cases that I hope I > will never ever have to debug in future. > > Greets, > > Marco > Thanks for articulating your reasons for your vote, I very much appreciate it. For the record, I don't think that my RFC precludes infix functions in a future RFC, and in fact I think setting up a new keyword makes that simpler in the future. Jordan --000000000000a3ef8405d4a3a609--