Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Deprecate and remove continue targeting switch »

[RFC] Deprecate and remove continue targeting switch

php.internals

Nikita Popov

8 years ago
Hi internals, Another small deprecation for your consideration... https://wiki.php.net/rfc/continue_on_switch_deprecation Regards, Nikita

Stas Malyshev

8 years ago
Hi! On 6/24/18 9:16 AM, Nikita Popov wrote:
> Hi internals, > > Another small deprecation for your consideration... > > https://wiki.php.net/rfc/continue_on_switch_deprecation
Not sure I understand - what this is improving? Yes, continue being the same as break is slightly surprising, but it doesn't seem to hurt anything and I don't think it happens too often, so why change it at all?
-- Stas Malyshev smalyshev@gmail.com

Nikita Popov

8 years ago
On Mon, Jun 25, 2018 at 7:53 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi! > > On 6/24/18 9:16 AM, Nikita Popov wrote: > > Hi internals, > > > > Another small deprecation for your consideration... > > > > https://wiki.php.net/rfc/continue_on_switch_deprecation > > Not sure I understand - what this is improving? Yes, continue being the > same as break is slightly surprising, but it doesn't seem to hurt > anything and I don't think it happens too often, so why change it at all? >
This RFC resolves the following issue: a) In PHP "switch" is considered a looping structure, for this reason "break" and "continue" both apply to "switch", as aliases. For PHP, these are reasonable semantics, as PHP supports multi-level breaks. It would be very questionable if "break N" and "continue N" could refer to different loop structures just because there is a "switch" involved somewhere. b) On the other hand, other languages, such as C and C-based languages, use a different behavior, where "continue" refers to the enclosing loop. As these languages don't have multi-level breaks, these semantics are also reasonable. This leaves us in a position where "continue" means different things in PHP and in other syntactically similar languages, causing confusing for programmers familiar with them. This is solved by simply prohibiting the case that is ambiguous. This is not a loss for PHP developers (who use "break" instead of "continue" for switch statements anyway), but it is a gain for programmers from other languages not familiar with this detail (as they get an error pointing them to one of the correct alternatives). All of this is not a big issue, it's just removing a papercut. IIRC this was originally motivated by me seeing some bug reports about this behavior. Nikita

Stas Malyshev

8 years ago
Hi!
> This leaves us in a position where "continue" means different things in > PHP and in other syntactically similar languages, causing confusing for > programmers familiar with them. This is solved by simply prohibiting the > case that is ambiguous. This is not a loss for PHP developers (who use
I see your point, in this case I'd add a notice for continue in switch that would say something along the lines "continue in switch is the same as break, did you mean "continue 2;"?"
-- Stas Malyshev smalyshev@gmail.com

Zeev Suraski

8 years ago
> -----Original Message----- > From: Nikita Popov [mailto:nikita.ppv@gmail.com] > Sent: Tuesday, June 26, 2018 9:28 PM > To: Stanislav Malyshev <smalyshev@gmail.com> > Cc: PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] [RFC] Deprecate and remove continue targeting switch > > This RFC resolves the following issue: > > a) In PHP "switch" is considered a looping structure, for this reason "break" and > "continue" both apply to "switch", as aliases. For PHP, these are reasonable > semantics, as PHP supports multi-level breaks. It would be very questionable if > "break N" and "continue N" could refer to different loop structures just because > there is a "switch" involved somewhere. > > b) On the other hand, other languages, such as C and C-based languages, use a > different behavior, where "continue" refers to the enclosing loop. As these > languages don't have multi-level breaks, these semantics are also reasonable. > > This leaves us in a position where "continue" means different things in PHP and > in other syntactically similar languages, causing confusing for programmers > familiar with them. This is solved by simply prohibiting the case that is > ambiguous. This is not a loss for PHP developers (who use "break" instead of > "continue" for switch statements anyway), but it is a gain for programmers from > other languages not familiar with this detail (as they get an error pointing them > to one of the correct alternatives). > > All of this is not a big issue, it's just removing a papercut. IIRC this was originally > motivated by me seeing some bug reports about this behavior.
I think it would be helpful to gauge the levels of these bug reports to understand whether it's worth the trouble. 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. Zeev

Rowan Collins

8 years ago
On 26 June 2018 at 19:27, Nikita Popov <nikita.ppv@gmail.com> wrote:
> a) In PHP "switch" is considered a looping structure, for this reason > "break" and "continue" both apply to "switch", as aliases. For PHP, these > are reasonable semantics, as PHP supports multi-level breaks. It would be > very questionable if "break N" and "continue N" could refer to different > loop structures just because there is a "switch" involved somewhere. >
I think this point should be highlighted: this is not just an unfortunate legacy decision, it would be *really bad* if "break 2;" sometimes referred to a different loop from "continue 2;" Other languages don't have that problem, because they don't have the "continue N" syntax. I'm +0.5 on Nikita's proposal to make this an error - it can't mean anything other than "continue with this switch statement", but that doesn't actually mean anything. The error is effectively saying "Can't 'continue' a switch, because it's not really a loop." Perhaps rather than deprecating and removing it, we should simply raise a Warning on its use: "Use of 'continue' to terminate switch; did you mean 'break', or to continue a loop instead?" In other words, "we've done what you asked, but we think it might not be what you meant". Regards,
-- Rowan Collins [IMSoP]

Niel Archer

8 years ago
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.

Rowan Collins

8 years ago
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? while($outer) {     while($inner) {         switch($foo) {             case 1:                 continue 2;         }     } } If so, I think that would be even more confusing. Regards,
-- Rowan Collins [IMSoP]

Stas Malyshev

8 years ago
Hi!
> Do you mean that this code would be valid in both PHP 7 and PHP 8, but > mean different things? > > while($outer) { >     while($inner) { >         switch($foo) { >             case 1: >                 continue 2; >         } >     } > } >
I think this would be unacceptable, because WTF potential and subtle code breakage that would result would be huge. If there are several wrapped loops, it'd be almost impossible to detect that you're now breaking a wrong loop. I think the only thing that could be changed is "continue;" - without an argument - and the thing that should happen is a notice that it may not do what you (might) think it's doing. If you use something like "continue 2;" I would assume you know what you're doing, this is a PHP-specific construct so it is reasonable to assume you checked it does what you think it does.
-- Stas Malyshev smalyshev@gmail.com

Niel Archer

8 years ago
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:

Rowan Collins

8 years ago
On 27 June 2018 at 16:14, niel <spam-free@blueyonder.co.uk> wrote:
> 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. >
In the proposal, the code is valid in all versions of PHP up to and including 7.3, *and represents the same algorithm in all versions*. The only difference would be the side-effect of issuing an additional deprecation notice; that's not "a different meaning". In PHP 8, under Nikita's proposal, the code would not be valid at all. The RFC reiterates this under "Unaffected PHP Functionality":
> The meaning of continue and break inside switch never changes, some cases
are just forbidden. In contrast, if we make the continue that previously referenced the switch now reference the loop, the same code will work in PHP 8, but now *represent an entirely different algorithm*.
> > 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. >> > >
If we change the behaviour, rather than removing it, we solve the first problem (C developers will get the semantics they're used to) but we will make the second problem worse (people with working code will need to understand why it now does something different). Regards,
-- Rowan Collins [IMSoP]

Stas Malyshev

8 years ago
Hi!
> In the proposal, the code is valid in all versions of PHP up to and > including 7.3, *and represents the same algorithm in all versions*. The > only difference would be the side-effect of issuing an additional > deprecation notice; that's not "a different meaning". In PHP 8, under > Nikita's proposal, the code would not be valid at all.
I agree with PHP 7 part but not with PHP 8 part. I think we should just leave the warning there.
-- Stas Malyshev smalyshev@gmail.com

Nikita Popov

8 years ago
On Wed, Jun 27, 2018 at 11:07 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi! > > > In the proposal, the code is valid in all versions of PHP up to and > > including 7.3, *and represents the same algorithm in all versions*. The > > only difference would be the side-effect of issuing an additional > > deprecation notice; that's not "a different meaning". In PHP 8, under > > Nikita's proposal, the code would not be valid at all. > > I agree with PHP 7 part but not with PHP 8 part. I think we should just > leave the warning there. >
I don't care particularly strongly about the actual removal, just having a warning would serve the purpose just as well for me. Should I just go ahead and implement the warning (with no intent of future removal), or do we want to still go through the RFC here? Nikita

Zeev Suraski

8 years ago
On Wed, Jul 4, 2018 at 5:15 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Wed, Jun 27, 2018 at 11:07 PM, Stanislav Malyshev <smalyshev@gmail.com> > wrote: > > > Hi! > > > > > In the proposal, the code is valid in all versions of PHP up to and > > > including 7.3, *and represents the same algorithm in all versions*. The > > > only difference would be the side-effect of issuing an additional > > > deprecation notice; that's not "a different meaning". In PHP 8, under > > > Nikita's proposal, the code would not be valid at all. > > > > I agree with PHP 7 part but not with PHP 8 part. I think we should just > > leave the warning there. > > > > I don't care particularly strongly about the actual removal, just having a > warning would serve the purpose just as well for me. > > Should I just go ahead and implement the warning (with no intent of future > removal), or do we want to still go through the RFC here? >
I think a sensible warning is fine and doesn't really require an RFC... Zeev

Christoph Becker

8 years ago
On 04.07.2018 at 16:51, Zeev Suraski wrote:
> On Wed, Jul 4, 2018 at 5:15 PM Nikita Popov <nikita.ppv@gmail.com> wrote: > >> On Wed, Jun 27, 2018 at 11:07 PM, Stanislav Malyshev <smalyshev@gmail.com> >> wrote: >> >>>> In the proposal, the code is valid in all versions of PHP up to and >>>> including 7.3, *and represents the same algorithm in all versions*. The >>>> only difference would be the side-effect of issuing an additional >>>> deprecation notice; that's not "a different meaning". In PHP 8, under >>>> Nikita's proposal, the code would not be valid at all. >>> >>> I agree with PHP 7 part but not with PHP 8 part. I think we should just >>> leave the warning there. >> >> I don't care particularly strongly about the actual removal, just having a >> warning would serve the purpose just as well for me. >> >> Should I just go ahead and implement the warning (with no intent of future >> removal), or do we want to still go through the RFC here? > > I think a sensible warning is fine and doesn't really require an RFC...
Would be fine for me as well.
-- Christoph M. Becker

Nikita Popov

8 years ago
On Wed, Jul 4, 2018 at 5:28 PM, Christoph M. Becker <cmbecker69@gmx.de> wrote:
> On 04.07.2018 at 16:51, Zeev Suraski wrote: > > > On Wed, Jul 4, 2018 at 5:15 PM Nikita Popov <nikita.ppv@gmail.com> > wrote: > > > >> On Wed, Jun 27, 2018 at 11:07 PM, Stanislav Malyshev < > smalyshev@gmail.com> > >> wrote: > >> > >>>> In the proposal, the code is valid in all versions of PHP up to and > >>>> including 7.3, *and represents the same algorithm in all versions*. > The > >>>> only difference would be the side-effect of issuing an additional > >>>> deprecation notice; that's not "a different meaning". In PHP 8, under > >>>> Nikita's proposal, the code would not be valid at all. > >>> > >>> I agree with PHP 7 part but not with PHP 8 part. I think we should just > >>> leave the warning there. > >> > >> I don't care particularly strongly about the actual removal, just > having a > >> warning would serve the purpose just as well for me. > >> > >> Should I just go ahead and implement the warning (with no intent of > future > >> removal), or do we want to still go through the RFC here? > > > > I think a sensible warning is fine and doesn't really require an RFC... > > Would be fine for me as well. >
Okay, thanks for the feedback. I've implemented the warning in https://github.com/php/php-src/pull/3364 and will merge the PR in a few days if there are no further objections. Nikita

Stas Malyshev

8 years ago
Hi!
> Should I just go ahead and implement the warning (with no intent of > future removal), or do we want to still go through the RFC here?
I think it's ok to just add the warning, unless somebody objects.
-- Stas Malyshev smalyshev@gmail.com

Niel Archer

8 years ago
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 >
Could you clarify the PHP 8 changes: "PHP 8 generates a compile error." Does this mean *any* use of continue in a switch is a compile error, or only continue without a number

Chase Peeler

8 years ago
On Wed, Jun 27, 2018 at 11:46 AM niel <spam-free@blueyonder.co.uk> 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 > > > > Could you clarify the PHP 8 changes: > > "PHP 8 generates a compile error." > > Does this mean *any* use of continue in a switch is a compile error, or > only continue without a number > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Something like this could make upgrading PHP against a large legacy code
base near impossible. If this was the ONLY thing that a developer in another language would have to grapple with in order to switch the PHP, it might be different. But, I would advise against potentially breaking a lot of code for something that provides no functional advantage, and, at best, might provide a slight syntactical improvement (and, I'm not convinced it even does that).
-- -- Chase chasepeeler@gmail.com

Rowan Collins

8 years ago
On 27 June 2018 at 16:45, niel <spam-free@blueyonder.co.uk> 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 >> >> > Could you clarify the PHP 8 changes: > > "PHP 8 generates a compile error." > > Does this mean *any* use of continue in a switch is a compile error, or > only continue without a number >
Neither:
> Continue can still be used inside switch statements, as long as it does
not target the switch. The lines marked "Deprecated" in the examples are the ones which will be compile errors. Regards,
-- Rowan Collins [IMSoP]

Nikita Popov

8 years ago
On Wed, Jun 27, 2018 at 5:59 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> On 27 June 2018 at 16:45, niel <spam-free@blueyonder.co.uk> 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 > >> > >> > > Could you clarify the PHP 8 changes: > > > > "PHP 8 generates a compile error." > > > > Does this mean *any* use of continue in a switch is a compile error, or > > only continue without a number > > > > > Neither: > > > Continue can still be used inside switch statements, as long as it does > not target the switch. > > The lines marked "Deprecated" in the examples are the ones which will be > compile errors. >
Thank you Rowan. I have added a code example to https://wiki.php.net/rfc/continue_on_switch_deprecation#unaffected_php_functionality to further clarify what is deprecated and what continues to be allowed. Nikita

Niel Archer

8 years ago
On 27/06/18 17:08, Nikita Popov wrote:
> On Wed, Jun 27, 2018 at 5:59 PM, Rowan Collins <rowan.collins@gmail.com > <mailto:rowan.collins@gmail.com>> wrote: > > On 27 June 2018 at 16:45, niel <spam-free@blueyonder.co.uk > <mailto:spam-free@blueyonder.co.uk>> 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 > <https://wiki.php.net/rfc/continue_on_switch_deprecation> > >> > >> Regards, > >> Nikita > >> > >> > > Could you clarify the PHP 8 changes: > > > > "PHP 8 generates a compile error." > > > > Does this mean *any* use of continue in a switch is a compile error, or > > only continue without a number > > > > > Neither: > > > Continue can still be used inside switch statements, as long as it does > not target the switch. > > The lines marked "Deprecated" in the examples are the ones which will be > compile errors. > > > Thank you Rowan. I have added a code example to > https://wiki.php.net/rfc/continue_on_switch_deprecation#unaffected_php_functionality > to further clarify what is deprecated and what continues to be allowed. > > Nikita >
Thanks, this makes it clearer.

Niel Archer

8 years ago
On 27/06/18 16:59, Rowan Collins wrote:
> On 27 June 2018 at 16:45, niel <spam-free@blueyonder.co.uk> 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 >>> >>> >> Could you clarify the PHP 8 changes: >> >> "PHP 8 generates a compile error." >> >> Does this mean *any* use of continue in a switch is a compile error, or >> only continue without a number >> > > > Neither: > >> Continue can still be used inside switch statements, as long as it does > not target the switch
> The lines marked "Deprecated" in the examples are the ones which will be > compile errors.
This appears to contradict your 'neither'. `continue` as part of a `case` will always be a compile error in 8? Apologies if my mention of switch previously was ambiguous. Will the PHP 8 version still require the programmer to count over the switches, i.e. in the third illustration, would the continue 3 still be needed for C-like behaviour? If that is true, then I really have no use for this proposal as it doesn't fix the problem, just moves it.

Yasuo Ohgaki

8 years ago
On Mon, Jun 25, 2018 at 1:17 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
> Hi internals, > > Another small deprecation for your consideration... > > https://wiki.php.net/rfc/continue_on_switch_deprecation > > Regards, > Nikita >
This great improvement. IMO. Since the issue is incompatibility between current "continue" and "break", how about provide a tool replace "continue" to "break" where it is applicable. (Raise error for invalid "continue" usage also. This would be a bug most likely.) Then there wouldn't be compatibility issue anymore. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Kalle Sommer Nielsen

8 years ago
Den tor. 5. jul. 2018 kl. 00.15 skrev Yasuo Ohgaki <yohgaki@ohgaki.net>:
> Since the issue is incompatibility between current "continue" and "break", > how about provide a tool replace "continue" to "break" where it is > applicable. > (Raise error for invalid "continue" usage also. This would be a bug most > likely.) > > Then there wouldn't be compatibility issue anymore.
I like the idea of a tool for such, but I think its better to implement it in some of the static analyzer projects like PHPStan and the like to catch these.
-- regards, Kalle Sommer Nielsen kalle@php.net

Christoph Becker

8 years ago
On 05.07.2018 at 00:20, Kalle Sommer Nielsen wrote:
> Den tor. 5. jul. 2018 kl. 00.15 skrev Yasuo Ohgaki <yohgaki@ohgaki.net>: > >> Since the issue is incompatibility between current "continue" and "break", >> how about provide a tool replace "continue" to "break" where it is >> applicable. >> (Raise error for invalid "continue" usage also. This would be a bug most >> likely.) >> >> Then there wouldn't be compatibility issue anymore. > > I like the idea of a tool for such, but I think its better to > implement it in some of the static analyzer projects like PHPStan and > the like to catch these.
Please note that the RFC has been superseded by <https://github.com/php/php-src/pull/3364>.
-- Christoph M. Becker

Nikita Popov

8 years ago
On Thu, Jul 5, 2018 at 12:51 AM, Christoph M. Becker <cmbecker69@gmx.de> wrote:
> On 05.07.2018 at 00:20, Kalle Sommer Nielsen wrote: > > > Den tor. 5. jul. 2018 kl. 00.15 skrev Yasuo Ohgaki <yohgaki@ohgaki.net>: > > > >> Since the issue is incompatibility between current "continue" and > "break", > >> how about provide a tool replace "continue" to "break" where it is > >> applicable. > >> (Raise error for invalid "continue" usage also. This would be a bug most > >> likely.) > >> > >> Then there wouldn't be compatibility issue anymore. > > > > I like the idea of a tool for such, but I think its better to > > implement it in some of the static analyzer projects like PHPStan and > > the like to catch these. > > Please note that the RFC has been superseded by > <https://github.com/php/php-src/pull/3364>. > > -- > Christoph M. Becker >
The warning addition in https://github.com/php/php-src/pull/3364 is merged now and I've marked the original RFC as withdrawn. Nikita