Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105644 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 37807 invoked from network); 8 May 2019 19:46:55 -0000 Received: from unknown (HELO mail-lj1-f195.google.com) (209.85.208.195) by pb1.pair.com with SMTP; 8 May 2019 19:46:55 -0000 Received: by mail-lj1-f195.google.com with SMTP id h21so1537621ljk.13 for ; Wed, 08 May 2019 09:51:06 -0700 (PDT) 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:content-transfer-encoding; bh=zyEvG4tKFw+dqnFFc49/bRHMkWVlRQrcOmbl4pS/SWE=; b=VpGGjpaeQXIu2hxvmShVLlwa8NKOf1mRFfJzTWM1GIecNVRzqQm0W4IkWE28ySBxay WWxU65kMUYDqEVCqhVCBrkH3E2oDfGmKooGFP/ZyzpXM7iVfMn3rCf5kxGk8sA5+9uEV SJxDd3Ynmwn9iFPyz1UWAtKvjLMCdwt4yH1JHhDqK8yr8FGJEGdvZ5OdT4eQUtIPoa+c Z/hVCwSFys3qk/cZk+Z3ut5GP4NwpbCUdYH1ijppO/ubX7NJ5UOy/hro088C33Ffm97W BZasznYLPWKVnI4l4B9ZGnAFK2rkFZ5vnHCzMjYusVk+gRKO9E3zle40zfWXcGNKE8q5 C6BA== X-Gm-Message-State: APjAAAXwIRUqyCkx/r8cRZytvX0MyIIgv3wuKFh61AGQ62TW738g/wg3 jJy+QOzyfTVI/iAwFo/K/CHObxXypoGKhoovC0E= X-Google-Smtp-Source: APXvYqz5SlBRg2y9eNN19pFUmmgG79GWIoy1/EYy1TTrK4csM3mUTLkXn5S3mAatvgO8CWpEhhX8/5Z06FssubZyt+g= X-Received: by 2002:a2e:4457:: with SMTP id r84mr21913089lja.112.1557334265385; Wed, 08 May 2019 09:51:05 -0700 (PDT) MIME-Version: 1.0 References: <8094526f-88d6-6d46-6f83-4165d65c064a@gmx.de> In-Reply-To: Date: Wed, 8 May 2019 10:50:48 -0600 Message-ID: To: Nikita Popov Cc: "Christoph M. Becker" , internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters From: levim@php.net (Levi Morrison) On Wed, May 8, 2019 at 2:06 AM Nikita Popov wrote: > > On Tue, Jan 22, 2019 at 6:59 PM Levi Morrison wrote: >> >> On Tue, Jan 15, 2019 at 1:27 PM Christoph M. Becker = wrote: >> > >> > On 04.01.2019 at 20:17, Levi Morrison wrote: >> > >> > > I intend to close the vote in a day or two, unless I hear of new> is= sues from Dmitry or others. >> > Any news here? >> > >> > -- >> > Christoph M. Becker >> >> I sent this a week ago to Christoph only; oops. >> >> I have not heard any news. The vote is now closed. The RFC passes 39 >> in favor to 1 against. >> >> Special thanks to Nikita and Dmitry who have helped find issues and >> review the patch. It will not be merged until the implementation >> quality is satisfactory. > > > As we're moving steadily towards 7.4 feature freeze, I'd like to discuss = what we want to do with this RFC... The current implementation doesn't work= correctly (I've done some more work in https://github.com/nikic/php-src/co= mmits/variance-7.4, but it's also incomplete) and I have some doubts about = how we're approaching this in general. > > This RFC really has two parts: > 1. The actual variance change. This is a very straightforward change and = there are no issues here. > 2. The ability to check variance across multiple consecutive class defini= tions. This allows type declarations to reference classes that are declared= later in the same file (but within one "block" of declarations). > > The second part is technically more dicey and somewhat arbitrary when see= n in the wider scope of how class hoisting and early binding work in PHP: W= hile PHP supports declaring classes "out of order" in some very simple case= s like this... > > class B extends A {} > class A {} > > ...it will not work for anything more involved than that, for example > > class C extends B {} > class B extends A {} > class A {} > > will already generate a "class not found" error. > > Now the variance RFC tackles one very specific part of this long-standing= issue: The types referenced in parameter and return types may be declared = later in the file (even if used variantly), but all other uses of the types= still need to respect the declaration order. > > I think that we should be separating these two issues (variance and decla= ration order), and land the simple variance support in 7.4, while tackling = the declaration order problem *in full* separately (in PHP 8, because I thi= nk we may want to make some BC breaking changes, in particular by making th= e class hoisting unconditional.) > > Thoughts on this approach? > > Nikita I fully support this approach. I will prepare a patch for simple variance in PHP 7.4. I intend to leave the existing test cases that will fail without supporting consecutive declarations, but marked as expected failures. I think in PHP 8 we can already benefit from the [always generate fatal error for incompatible method signatures RFC][1]. We might also be able to make some improvements with compile-time errors on invalid "parent::" usage (previously done for PHP 7.4 but [backed out][2]), which might make things a bit more straightforward (it might not -- turns out parent is not exactly what I thought it was). [1]: https://wiki.php.net/rfc/lsp_errors [2]: https://github.com/php/php-src/commit/deb44d405eb27a6654ad9a57c1e5f6= 41218b22a4