Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102684 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60205 invoked from network); 10 Jul 2018 08:05:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jul 2018 08:05:31 -0000 Authentication-Results: pb1.pair.com smtp.mail=vsuraski@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=vsuraski@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.196 as permitted sender) X-PHP-List-Original-Sender: vsuraski@gmail.com X-Host-Fingerprint: 209.85.216.196 mail-qt0-f196.google.com Received: from [209.85.216.196] ([209.85.216.196:34504] helo=mail-qt0-f196.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7A/5D-49043-BC8644B5 for ; Tue, 10 Jul 2018 04:05:31 -0400 Received: by mail-qt0-f196.google.com with SMTP id m13-v6so17595595qth.1 for ; Tue, 10 Jul 2018 01:05:31 -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=fgqFQv6OtThZXkCQ+9u4AIcwnECe0V4yNz1/8s1ugbE=; b=kDwWRMsvnYwjvVFKbKyD0/VMFPbXmUNneDmkPou3kQp7r32oQmbOR+gSSY5RTyAsS9 O0rYOZ/c7JlSuLXDiObrJa6VhKOOhkLtfa3rwFbhpjd47IAYzYiAcMe3oy0wDKiAuWzr RLoad41xHhe8QIdEfu3YVOLtyjfjpE70YAPzDqpQQajF3Iua5Dwo9rAaD2Huypuvctlg suu3wcOBfp8BxMFvuGh/ci4b8JpVEsdqbXNLMXBvkctfDJcItE9vZSmxuSmyCt2r+C9O tfUPAA/4ROW1K2AfWk+cBQGGr1FETFCA3X5vZGrPckXvvX+XacXSGuK3tVzPc/7iGCpU FovA== 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=fgqFQv6OtThZXkCQ+9u4AIcwnECe0V4yNz1/8s1ugbE=; b=CYgPYoaNMFfoFSsTwVjVV7mO1v9mTOFdk914osSqPSaUEaBevsbSJ0gJTuEzF0yv+x JWpBRsEJpgaQdkYnOFC0DX8KO2mYaf36RWBznf3XqaOSBWkGsmwdoPoU5NqNMtC+ghj3 1sRJF2QiBBg8nxkciCfD/lbkqGvdAel3Uo6YIVrnAFHLWkjCA7kroQe1bZOUomAdPk7K 2RHEc88/bABW7rFM3ISbc1U/a8WcXPlW/0jKezwW53rJRKcoenUXJnnWceYojuuIaABX QB2LI3dPHj6jpa2NGOwRC42ytGGCCMDAllTkVJfWXpHA9CWviXfBH92j5YmgNTINRvin 3BLA== X-Gm-Message-State: APt69E3wbxASJW0X6oasDoe82fdTxjAGNDWNYm7dmTIB8rvChwTsZvpm 0wl5XKHOOb7gEj20elkPV3o3yvx2xs4IlbTCRAA= X-Google-Smtp-Source: AAOMgpeVTSuOD91mzn9mwtR/1eNTa1Pglh4889bXwboktVaMPNU09zF5O6W2fZSGedpebpwkfTXpLYS1lxOBClR97Iw= X-Received: by 2002:aed:36a9:: with SMTP id f38-v6mr22787745qtb.64.1531209928583; Tue, 10 Jul 2018 01:05:28 -0700 (PDT) MIME-Version: 1.0 References: <5153610d-abed-b21a-ec55-56d967128cae@gmail.com> <017101d41815$95118440$bf348cc0$@gmail.com> In-Reply-To: Date: Tue, 10 Jul 2018 11:05:17 +0300 Message-ID: To: Nikita Popov Cc: Sara Golemon , "Christoph M. Becker" , Kalle Sommer Nielsen , Internals Content-Type: multipart/alternative; boundary="000000000000deafd60570a097d6" Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3 From: vsuraski@gmail.com (Zeev Suraski) --000000000000deafd60570a097d6 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 10:36 AM Nikita Popov wrote: > On Tue, Jul 10, 2018 at 8:16 AM, Zeev Suraski wrote: > >> >> >> > -----Original Message----- >> > From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara >> > Golemon >> > Sent: Monday, July 9, 2018 5:41 PM >> > To: Christoph M. Becker >> > Cc: Nikita Popov ; Kalle Sommer Nielsen >> > ; Internals >> > Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3 >> > >> > On Sun, Jul 8, 2018 at 5:41 PM, Christoph M. Becker >> > wrote: >> > > Sorry, that there has not been any decision yet. However, Sara >> > > suggested that this decision is not solely up to the RMs[1], and I >> > > wouldn't know how to decide it then[2], since there has been at least >> > > one objection[3]. >> > > >> > To clarify, it's ultimately an RM decision, but it should be guided by >> the larger >> > internals@ group. >> > >> > The way I read Zeev's objection is that it's primarily against TP, and >> not against >> > pushing out the FF per se. I would recommend (in a non-RM, unofficial >> capacity) >> > pushing out the FF (not necessarily GA, but we can make that decision >> later). If >> > these last minute things pass, they go in. If they fail, then all >> we've done is >> > burned a month. >> >> It's a bit of both really. >> >> I hope that with all things considered (the little time we have left, the >> little concrete discussion that happened so far as a result, the >> inconsistency of allowing such a vote to push out feature freeze, the scope >> of this feature being a lot more suitable for a major release, and our >> inability to fix/improve other related elements at the same time) - Nikita >> will propose this for 8.0 instead of 7.x. >> > > To make sure there are no unreasonable expectations involved in this > decision: If this feature will not go into PHP 7.3, then it will in all > likelihood go into PHP 7.4 instead. I think I can safely say not just on > behalf on Bob and myself, but also on behalf of the wider PHP community, > that we are not willing to sit on this feature for 2.5~3 years until a > hypothetical PHP 8, even though it is essentially ready *now*. Of course, > this is not my decision to make, but as Sara put it, that's the writing on > the wall. By deciding not to include this in PHP 7.3, we are essentially > making an implicit decision that PHP 7.4 is going to be a relatively > ordinary feature release rather than a deprecation-only one. (Which is fine > by me really, I don't like the idea of a release that's all stick and no > carrot.) > Thanks for choosing not to push it for 7.3. At the same time - I think the push for inclusion in 7.4 will be regrettable. Other parts of what I'd like to see in PHP 8 is, in fact, ready and can theoretically become a part of PHP 7.4 (even JIT, potentially). The reason we're doing it is twofold - one, that's the expectation around major releases - that they will come with major new features; And two, perhaps more importantly - is that big features sweeten the deal associated with migrating to a new major versions, with the incompatibilities introduced and the code audits required. I obviously know it's extremely difficult to sit on new working code for prolonged periods of time - but it can very much be the right thing to do. We did exactly that with the phpng codebase (which introduced virtually zero incompatibilities, and could in theory be included in PHP 5.7), and we're likely going to do that again with JIT and FFI. Either way, I'll state my case when the discussion becomes relevant again. In the PHP 8 RFC that I'm hoping to begin drafting in the near future, my goal is to present 7.4 as a 'deprecation mostly' version, which while it won't be forbidden to include new functionality in it, it will be discouraged (with probably no 'teeth' to this discouragement, i.e. a successful vote would still land a new feature into 7.4). Zeev --000000000000deafd60570a097d6--