Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108993 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 85222 invoked from network); 12 Mar 2020 11:45:07 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 Mar 2020 11:45:07 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id F063F1804A7 for ; Thu, 12 Mar 2020 03:06: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-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) (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 ; Thu, 12 Mar 2020 03:06:28 -0700 (PDT) Received: by mail-il1-f178.google.com with SMTP id l14so4889188ilj.8 for ; Thu, 12 Mar 2020 03:06:28 -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=b45CxZLhz5QZ8QhFJq5UPhT2DfCui2J0ATZ4mH5njGo=; b=MAYBEuO9M0lSncz0q+UbBdE85J/YC1LnEmz61ykui5sxfyahHZcu3scdP9nMbs23kW dmTCcoBpJNqT4Y+V8FQCpeK/fuInMK7Ej/g140Y5GfBZDBtLwxxi3zJQQDbpAgyDU6B9 k6rs3FITje3/XFSJPZyHwEOsykwevoN2Y3KmCWpoT5KezW2wnJxRcJKilTT60Dw7OHr0 UjDjYi9Ce5YRJdjA821ldEPSPGNdrFWpyTub+po01WKnWMbOqOGYZN1vDZ9MyQYQNGtD lq/bYSwhs1tFsdJ184x7vyk9sGokKBxkDK+ROrdK46M1tfZVPe7ufJgNPto+mcTHin1Y yJcQ== 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=b45CxZLhz5QZ8QhFJq5UPhT2DfCui2J0ATZ4mH5njGo=; b=suMdL7c00v7Cm9IdaQg18mZh0PmewWjv3LUjriThYeoAGbKkQU3chOHi3rfKPc0lsW 0X7M9NGqeDEbgfhn6SOlTPZOVZ4gdqneiUr0ftXdyZOeE1us1BEmr76oUzm1hY16jVsd YDf3ct/+zjyjenGOjLmUCWm0RLDYp0h3g8bftg78LVXJk5fKkAGgPYbZQGHTNfRdWnT2 viX5eUpgJKXVaiF8Hfc4Dtf+3Eeq7RDnA21DO/lwCEKS/pN88zYvqYCHjMeWuQ+j/QH2 NQOTEYR+C0pWlB1pUGIoqxzEkhmsOd2zi0EbmxvcCxKBmFndivFjBJKgX1MAuLuVdkC8 wFTg== X-Gm-Message-State: ANhLgQ1ywtiXfFWU71WEwPNmVJ1EjX5vXZ6DVvcCmjVXfuHIy0KzYjU1 /CBHeMkcZKGPLM54bhYEA8+/6U8FLIfO0+h5IxXmrt2i X-Google-Smtp-Source: ADFU+vtcTFR1SS/AwZA+GRMPvLo0LnQr0dvS58ZK+1h4jWh+6tUhTriQM4wIWBLFUCZsUaVMbzrBXiSSEpDSNBx7Dl8= X-Received: by 2002:a92:d702:: with SMTP id m2mr6993493iln.149.1584007585331; Thu, 12 Mar 2020 03:06:25 -0700 (PDT) MIME-Version: 1.0 References: <005101d5edae$7b7c3e10$7274ba30$@gmx.de> <8776962f-71ac-0ee3-a1b8-42eb2926eef0@gmx.de> <3ac8a6c1-a4e2-ecc9-053d-1c1a955a0325@gmx.de> In-Reply-To: Date: Thu, 12 Mar 2020 10:06:14 +0000 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="00000000000072041105a0a58126" Subject: Re: [PHP-DEV] Re: [RFC] Userspace operator overloading From: rowan.collins@gmail.com (Rowan Tommins) --00000000000072041105a0a58126 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 12 Mar 2020 at 08:31, Jan B=C3=B6hmer wrote: > On 11.03.2020 at 10:50, Christoph M. Becker wrote: > > On 11.03.2020 at 10:22, Nikita Popov wrote: > >> Does anyone else have thoughts on the ability to specify the supported > >> types in the signature? > > I agree that we should not introduce (this special case of) overloaded > > functions. > > I have thought about this the last days, and I agree with you. Therefore > I have removed this feature from the RFC. > I've been thinking about it as well, and am not sure what happens _without_ it in a case like this: # initial class, only overloads + on instances of itself class A { public static function __add(A $lhs, A $rhs) { // ... } } # in some third-party library class B { public static function __add(A|B $lhs, A|B $rhs) { // ... } } $a =3D new A; $b =3D new B; var_dump($b + $a); # calls B::__add($b, $a); OK var_dump($a + $b); # calls A::__add($a, $b), which is a TypeError If the engine doesn't catch the TypeError, it will never try B::__add($a, $b) in the second case, so presumably the TypeError will just be thrown to the user, which doesn't seem very helpful. Perhaps the simplest solution is to have a restriction that the operator overloads _must not_ specify types in their signature? Regards, --=20 Rowan Tommins [IMSoP] --00000000000072041105a0a58126--