Re: [RFC] Deprecate and remove continue targeting switch

From: Date: Wed, 27 Jun 2018 15:14:42 +0000
Subject: Re: [RFC] Deprecate and remove continue targeting switch
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-102487@lists.php.net to get a copy of this message
On 26/06/18 21:49, Rowan Collins wrote:
On 26/06/2018 20:28, niel wrote:
On 24/06/18 17:16, Nikita Popov wrote:
Hi internals, Another small deprecation for your consideration... https://wiki.php.net/rfc/continue_on_switch_deprecation Regards, Nikita
IMO the proposed illustrations will lead to as much, if not more, WTF from other language users as current behaviour. Why? Because the programmer still has to account for the 'switch' in how continue works. This will just cause a BC problem for older code without adding anything for people new to PHP. My suggestion, is to make the break (no pun intended) be clean. Deprecate use of continue from usage to escape switch completely in next PHP, then remove that functionality in PHP 8.
Do you mean that this code would be valid in both PHP 7 and PHP 8, but mean different things?
How is that different to the illustrations provided? That code is valid in PHP 7.0-7.3 but will have different meaning in 7.3.
while($outer) {
     while($inner) {
         switch($foo) {
             case 1:
                 continue 2;
         }
     }
} If so, I think that would be even more confusing. Regards,
Ultimately, I was trying to express what Zeev said better:
Ultimately - even after this change, C developers won't be able to use the C semantics they're used to, as (e.g. in the example in the RFC) - 'continue;' won't work as they'd expect - and they'd have to acquaint themselves with 'continue 2;'. It's true that if we 'force' them to acquaint themselves with multi-level loop control structures there's reduced 'continue;' erroneously. But unless this is really A Thing, as in, something pretty common - I think the mess involved with forcing people who have working code to try and (a) understand the change, and (b) understand their (potentially quite ancient) code flows may outweigh the benefits.


« previous php.internals (#102487) next »