Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102444
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
To: internals@lists.php.net
References: <CAF+90c8S3UK3xakJQ4eD1mCMvBAdms2_d5aDd0oOZHfi67Mn9Q@mail.gmail.com>
 <CAESVnVqKqLDcbrTwzSD2qms32kF3FROa6XGXp9UEgp2MLjDvPw@mail.gmail.com>
 <DM5PR0201MB35423C070BADA25899A12E1EAC740@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <CAFMT4NoB-WvTZ=tEqeMMOdt0vDxPLqe-_Ab93xqeKp1GXYjfew@mail.gmail.com>
 <DM5PR0201MB3542CDDEC128637665333A61AC4B0@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <CAFMT4NrWt0APfRKaDc_m0WXT=i2+qRLZkDutVofHfrsk4dm3_w@mail.gmail.com>
 <4CD11D3A-D799-46CF-9DD0-E34552FB15CD@gmail.com>
 <4552e1c3-b538-17ab-95fd-708dfa4f0d5a@lange.demon.co.uk>
 <CAPKYkKzY2V11d0GaeZfuUm91K2fskHgxyYJtXA4AsZn-Lv7gGw@mail.gmail.com>
 <CAJHtznyB0oQVstisdOiqyM3uyJa8Hd7VM-RbE4nYNbLPg2Hpzw@mail.gmail.com>
 <CAEUnE0enV1Abhc6bqvpn-KsMzC4Zwi2WC56CQpznw4ZVRtffnQ@mail.gmail.com>
Message-ID: <80f417a1-8b48-40a9-10f6-2cce7e9b1334@gmail.com>
Date: Mon, 25 Jun 2018 22:08:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CAEUnE0enV1Abhc6bqvpn-KsMzC4Zwi2WC56CQpznw4ZVRtffnQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] PHP 8 next?
From: rowan.collins@gmail.com (Rowan Collins)

On 25/06/2018 20:34, Michael Morris wrote:
> So, about that Ternary operator?
>
> My understanding is that major releases are the only ones allowed to have
> breaking changes. Correcting the ternary operator to work like it does in
> all other languages is a small example.


I don't think it's a good idea to turn this thread into a list of every 
possible change we might want in PHP 8, but there is a general point to 
be made here: the rule is that if you have a clear breaking change, it 
is definitely not allowed in a minor release; not that it automatically 
will be allowed in a major release.

Even a major release should maintain some compatibility - in particular, 
it should be possible to write code that runs correctly on both the 
previous and new versions. For instance: removing the old way of doing 
something because a new way is already available, or making something an 
error that was previously an avoidable warning.

In this example, changing the associativity directly would mean the same 
code would run in both versions, but with different results, and that is 
going to cause a lot of headaches. On the other hand, making it 
*non-associative*, so that it was an error to write ambiguous code, 
would probably save a lot of headaches.

Again, this feels less of a hardship if we plan major versions further 
ahead: we might pencil in the new behaviour for 9.0, and be able to put 
a date on that.

Regards,

-- 
Rowan Collins
[IMSoP]