Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110322 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 91162 invoked from network); 31 May 2020 22:38:36 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 31 May 2020 22:38:36 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B503B1804DD for ; Sun, 31 May 2020 14:20:07 -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=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, 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-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) (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, 31 May 2020 14:20:07 -0700 (PDT) Received: by mail-il1-f169.google.com with SMTP id 18so7509907iln.9 for ; Sun, 31 May 2020 14:20:07 -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=T/btEknnUUSCmG4byg8DebrJdHTeVUtvV3X81HR7P4o=; b=RtwCe2UdwlgHF7DPC2vmXFdHDHqpkj0N6nA2msnRQWhgLMkMmazJdMZYkvxnAAmR1G +4R8I6Sl54em2hs8/e/R/R+u55LywV+vgw3vGOI4t+1tnSD3MBBVcJE1wYkmiVetWcXp mRAsqtqBAWXw35fPn6Lp5AEXMABaNblB+9j9okmuzIShTmNMmczGumZnW5S8M3XbuwlD iJX1uBRo5qxxcEcgZkuZo+3+M5gami7kjn8pl6cXfywfCusL2z2MjfowVYf24lrFKnnI pntGBte5b/T9393mOMoKKm6/xanx02A8t5/xn5fftI5tuDDpGkKhgntjTehY3gAqZOWP FmrA== 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=T/btEknnUUSCmG4byg8DebrJdHTeVUtvV3X81HR7P4o=; b=dFnJBBBTEJwnmSFt3+clOEPqLiFMDQNTJ4uljaGGTCBZ7pk+yssqf9/iQIH0y7YuLR bRX4RhcHXmn1yAmPsY8GhPwp4Y6J+BhPavwpBWG4hD5ukfkaOXbjOKV7qutMUhDETl3E 5KVrI6fOePGQP1L8nmgrYt5oVBWdJndLAWyq/06fDC8cWnKFTU6TWZ5i37/uJwszdxYa YnSHfYv5e8InOX23TjZ5e1lx1UogvZUotD3fOWmD9nXK2/tTdCgosQPV15cY154EgqOS YsHd8rEIa5bytosWOhO9830CqmdA3qgS7S/icTc9mt0qzOhY4NOapZersT66J0sHYO2F GJng== X-Gm-Message-State: AOAM530/v4genmvi52TdkSL87+Fnes2hMSiQoJ5W6PMzvr9iqnqxE6P7 iS8t3+VmhZQtElDmRvMWBr5oc6CibF8eAH86szk= X-Google-Smtp-Source: ABdhPJyOkUzlAJVU20zlKtMg6L1PjIkPg0u7OMMiIRq2M5DHZGmfWK9VOwKV1dTBsDwhms9XwSlHI9UFKG/do0KQ3rw= X-Received: by 2002:a92:778b:: with SMTP id s133mr16052897ilc.99.1590960006512; Sun, 31 May 2020 14:20:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sun, 31 May 2020 23:19:50 +0200 Message-ID: To: Nikita Popov Cc: PHP Internals Content-Type: multipart/alternative; boundary="0000000000000a440205a6f83e0b" Subject: Re: [PHP-DEV] [VOTE] Ensure correct signatures of magic methods From: carusogabriel34@gmail.com (Gabriel Caruso) --0000000000000a440205a6f83e0b Content-Type: text/plain; charset="UTF-8" On Sun, 31 May 2020 at 15:57, Nikita Popov wrote: > On Fri, May 29, 2020 at 6:45 PM Gabriel Caruso > 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. > > 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). > > and report as such from reflection? > I need more clearance on this one: are you asking how magic methods are reported via Reflection and if that will be changed? > > Nikita > --0000000000000a440205a6f83e0b--