Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110620 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 93288 invoked from network); 17 Jun 2020 09:47:50 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 17 Jun 2020 09:47:50 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 718FC1804CB for ; Wed, 17 Jun 2020 01:33: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-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (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 ; Wed, 17 Jun 2020 01:33:27 -0700 (PDT) Received: by mail-lj1-f179.google.com with SMTP id n23so1815129ljh.7 for ; Wed, 17 Jun 2020 01:33: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 :cc; bh=CYYzM3ao+/R5KTCAm39gFOBuJXHe3qM1p9PTkPrZTwA=; b=eoZ8q3bcq1d1iHGTZLQqjlZpwEN615B5MBEbqf8QwlzP+OWtEg1nALT6sMSDWGRJiE FJ9J8B3xa6bjY2jFiQxvgqss9Jrape6QzspY2BwD5fEjz9mRp3QeSySWwr6RVyZOTVvT gle2UWaySoxRMVRseQwvh5g4b21vlxFq9gjnb4GMJgKUJtT2p8rf+H1rOYJDaD06m8vb zmgBfCQvpEjJ7tl3+MMsB1R4KRQRsptQeFu2w3rcO5Lld5zqSvGl/2vh3NjE5/W/wNjG wY3QVgfqFhfyXPJXhp2nzHXG6l4Bj4TM/66kGZnEndMxWPLODJ41hDtllgWTB1PcePSw 6dnw== 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:cc; bh=CYYzM3ao+/R5KTCAm39gFOBuJXHe3qM1p9PTkPrZTwA=; b=VRV5LLCJmHJSHCDp9+8QyJxMpJyE7CocdyZ84nAVXLTLpYTbZmu7P7SwMuV9tvMRVj Pz6JelZc+myk6gClaKABk5uWSkhQ5a6RtzvWXB/XgbGg1/+r2M4c7sF/f3PKq2oirHgD Nq57crQNldyFaSUnVTOlVoqGNcXXUaxdYBL/PaJ5j7XZKIyxaCFny3vVjLrFUIXwHZEK 59NBD9i+lIHeHEgO04V/+jhhoFelsPe8WfvTnny15RNX6Gd43fn0vtUU+0qKyFQB04gQ wgqNNIOiEu7rdrHQ487EObFhu14iq8yxC450YuctQhaVnGxI+jVfctPMAziXu7tik49k qLcw== X-Gm-Message-State: AOAM533B7CEenVG0oDv9DcowUYX+e2n6qEzUoKzOVFOLUr1SwVd2G0n4 z701ZULdsNORbgXszgoOnOxcvu13Svtytd3LQhw= X-Google-Smtp-Source: ABdhPJxbEV0WwCOK6qMs02s5YTVqUU68E6PNHsbFBWXLcIxmbu2ml5kdoXCVzy5e9WFbizYgI655MQOJiAK9J9JDUyc= X-Received: by 2002:a2e:b550:: with SMTP id a16mr3655474ljn.345.1592382805741; Wed, 17 Jun 2020 01:33:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 17 Jun 2020 10:33:09 +0200 Message-ID: To: Gabriel Caruso Cc: PHP Internals Content-Type: multipart/alternative; boundary="0000000000007b95ab05a84383a8" Subject: Re: [PHP-DEV] [VOTE] Ensure correct signatures of magic methods From: nikita.ppv@gmail.com (Nikita Popov) --0000000000007b95ab05a84383a8 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 3, 2020 at 11:11 PM Gabriel Caruso wrote: > On Wed, 3 Jun 2020 at 12:32, Nikita Popov wrote: > >> On Sun, May 31, 2020 at 11:20 PM Gabriel Caruso < >> carusogabriel34@gmail.com> wrote: >> >>> On Sun, 31 May 2020 at 15:57, Nikita Popov wrote: >>> >>>> On Fri, May 29, 2020 at 6:45 PM Gabriel Caruso < >>>> carusogabriel34@gmail.com> wrote: >>>> >>>>> Hello, internals! >>>>> >>>>> I have opened the voting for >>>>> https://wiki.php.net/rfc/magic-methods-signature. >>>>> >>>>> The voting period ends on 2020-06-19 at 18h (CEST). >>>>> >>>> >>>> The RFC is a bit unclear on what is actually being proposed. It says >>>> >>>> > This RFC proposes to add parameter and return types checks per the >>>> following details. >>>> >>>> and goes on to list (reasonable looking) magic method signatures, but >>>> does not say how exactly those types are going to be checked. Is this going >>>> to require exactly the same signature, or is this going to be in accordance >>>> with variance rules? For example, are all of the following signatures valid >>>> under this RFC? Only the first two? None of them? >>>> >>>> // Narrowed return type from ?array >>>> public function __debugInfo(): array {} >>>> >>>> // Narrowed return type from mixed >>>> public function __get(string $name): int {] >>>> >>>> // Widened argument type from string >>>> public function __get(string|array $name): mixed {} >>>> >>> >>> >>> They are going to be checked following the variance rules, not the >>> *exactly* same as the RFC. I'll mention this, thanks for point it out. >>> >>> Assuming this, your examples: >>> >>> 1 and 2. Will be valid, following the rules introduced by the `mixed` >>> RFC. >>> >>> 3. Is that allowed in PHP? If so, the RFC will compliance with that. >>> >> >> Yes, it is allowed. It makes little sense in this particular case, but >> it's allowed. >> > > Ok, so let's allow that as well. I'll cover that with tests. > > >> >> Also, is omitting the return type still permitted, even though it would >>>> nominally violate variance? >>>> >>>> public function __debugInfo() {} >>>> >>> >>> Yes, this hasn't changed. The RFC only affects *typed* methods. >>> >> >>>> Finally, if omitting the return type is permitted, will an implicit >>>> return type be added, like we do for __toString()? Would the method >>>> automatically become >>>> >>>> public function __debugInfo(): ?array {} >>>> >>> >>> An implicit return type won't be added for any of the magic methods. I >>> believe that's a huge BC, and I don't want to debate that for PHP 8 (maybe >>> PHP 9, yes). >>> >> >> Why would this be a BC break? To make sure we're on the same page, I'm >> suggesting to do the same as we do for __toString(), where if you declare >> >> public function __toString() {} >> >> we automatically convert it into >> >> public function __toString(): string {} >> >> internally. >> > >> We could do the same for all other magic methods, and I don't think it >> would introduce a particularly severe BC break. >> >> We did this for __toString() to work with the Stringable interface, and >> we don't have the same requirement for other magic methods, but I still >> think it's worth considering this for consistency reasons. >> > > Ok, let me see if I understood it: so if someone creates a > > public function __set($name, $value) {} > > we would automatically convert (as per this RFC) to > > public function(string $name, mixed $value): void {} > > internally, right? Isn't this a BC if someone is returning something > inside that method? > Yes, that's right, there would be a BC break. I ran some analysis for the void cases (excluding constructor/destructor) with the following results on top 2k packages: https://gist.github.com/nikic/9bc4f025a85c322a14c21128d8202c64 There were 91 issues found. I have no easy way to analyze the non-void cases. The BC issue is also being discussed in the constructor thread. So yes, just adding the type automatically may not be possible :( Or no, are you talking that we only convert that for Reflection purpose? > No, that would make Reflection lie. We don't want Reflection to lie :) Regards, Nikita --0000000000007b95ab05a84383a8--