# Labeled Break (nothing at all whatsoever to do with GOTO)

- Thread: https://externals.io/message/20863
- Original archive: https://news-web.php.net/php.internals/20863
- Started by Sara Golemon on 2005-11-30T01:40:32+00:00
- Messages: 28
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/20863.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #20863 — Sara Golemon — 2005-11-30T01:40:32+00:00

URL: https://externals.io/message/20863#20863

But first, this word from our sponsor:
Group A wants anything resembling goto to burn in the fires of hell
Group B wants full non-crippled goto or nothing at all
Group C wants partial goto (non-backward jumping) or nothing at all
Groups B and C both (generally) want it called either GOTO or JUMP, not
BREAK

Since no group this size will ever come to an agreement on something this
divisive, I'd like to turn the topic to a completely different language
feature which (might) please enough people to get a rousing consensus.

Actual labeled breaks.  Not the break+jump that was proposed earlier in the
guise of a break statement, but an actual straightforward, no funny-business
labeled break which does no more and no less than the current break N;
construct, but allows the use of identifier labels rather than numbers which
may change as the result of the addition or removal of break containers.

http://libssh2.org/patches/true_labeled_break.diff

Usage:

while FOO ($condition) {
    /* statements */
    break FOO;
    /* more statements */
}

Or a stacked example:

for FOO(;;) {
    while BAR (true) {
        foreach BAZ ($arr as $val) {
            switch Foof ($value) {
                default:
                    do Plop {
                        break FOO;
                    } while (false);
            }
        }
    }
}

Notes on this implementation:

* Labels can't be repeated in an ancestral line.  For example, the parser
will throw an ERROR on the following:
while FOO(true) {
    while FOO(true) {
        break FOO;
    }
}

* Labels can be repeated by siblings.  I'm not married to this, and it
certainly has WTF potential.  This behavior is easily modified to throw an
error.  I left it permissable because there was no technical reason to
disallow it.  For example, the following is okay:
while FOO(true) {
    break;
}
while FOO(true) {
    break FOO;
}

* Labeled breaks also apply to continue;  For example:
foreach FOO($arr as $key => $val) {
    if ($key % 2) continue FOO;
    if (empty(%key)) break FOO;
}

---

## #20864 — Robert Cummings — 2005-11-30T01:51:54+00:00

URL: https://externals.io/message/20863#20864 · In reply to: #20863

> But first, this word from our sponsor:
> Group A wants anything resembling goto to burn in the fires of hell
> Group B wants full non-crippled goto or nothing at all
> Group C wants partial goto (non-backward jumping) or nothing at all
> Groups B and C both (generally) want it called either GOTO or JUMP, not
> BREAK
> 
> Since no group this size will ever come to an agreement on something this
> divisive, I'd like to turn the topic to a completely different language
> feature which (might) please enough people to get a rousing consensus.
> 
> Actual labeled breaks.  Not the break+jump that was proposed earlier in the
> guise of a break statement, but an actual straightforward, no funny-business
> labeled break which does no more and no less than the current break N;
> construct, but allows the use of identifier labels rather than numbers which
> may change as the result of the addition or removal of break containers.
> 
> http://libssh2.org/patches/true_labeled_break.diff
> 
> Usage:
> 
> while FOO ($condition) {
>     /* statements */
>     break FOO;
>     /* more statements */
> }
> 
> Or a stacked example:
> 
> for FOO(;;) {
>     while BAR (true) {
>         foreach BAZ ($arr as $val) {
>             switch Foof ($value) {
>                 default:
>                     do Plop {
>                         break FOO;
>                     } while (false);
>             }
>         }
>     }
> }
> 
> Notes on this implementation:
> 
> * Labels can't be repeated in an ancestral line.  For example, the parser
> will throw an ERROR on the following:
> while FOO(true) {
>     while FOO(true) {
>         break FOO;
>     }
> }
> 
> * Labels can be repeated by siblings.  I'm not married to this, and it
> certainly has WTF potential.  This behavior is easily modified to throw an
> error.  I left it permissable because there was no technical reason to
> disallow it.  For example, the following is okay:
> while FOO(true) {
>     break;
> }
> while FOO(true) {
>     break FOO;
> }
> 
> * Labeled breaks also apply to continue;  For example:
> foreach FOO($arr as $key => $val) {
>     if ($key % 2) continue FOO;
>     if (empty(%key)) break FOO;
> }

Hello, I represent group B (not in any way officially or anything else
that might give my words an iota of weight), but I (*cough cough*) WE
think that the above break system would make a terrible system for
finite state machines. 

Additionally at this time I'd like to make clear that we are in support
for full uncrippled break WITHIN scope. Group A can feel free to travel
to the burning fires of hell and have a barbecue, and group C should
join us so that at least they get what they want as a subset.

As an aside, from what I've read, the multitude were in favour of
unrestricted goto. Quite a few were in favour of none at all (but not as
many as in group B) and those in favour of none at all had a large
subset that were in favour of unrestricted goto in the event that group
B should get their way :)

Cheers,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

---

## #20865 — Marcus Boerger — 2005-11-30T01:52:59+00:00

URL: https://externals.io/message/20863#20865 · In reply to: #20863

Hello Sara,

  nice work, clean patch, good solution - thanks! what more can one say?

best regards
marcus

p.s.: I'll have the thousands of replies on this thread on ignore :-)

Wednesday, November 30, 2005, 2:40:32 AM, you wrote:

> But first, this word from our sponsor:
> Group A wants anything resembling goto to burn in the fires of hell
> Group B wants full non-crippled goto or nothing at all
> Group C wants partial goto (non-backward jumping) or nothing at all
> Groups B and C both (generally) want it called either GOTO or JUMP, not
> BREAK

> Since no group this size will ever come to an agreement on something this
> divisive, I'd like to turn the topic to a completely different language
> feature which (might) please enough people to get a rousing consensus.

> Actual labeled breaks.  Not the break+jump that was proposed earlier in the
> guise of a break statement, but an actual straightforward, no funny-business
> labeled break which does no more and no less than the current break N;
> construct, but allows the use of identifier labels rather than numbers which
> may change as the result of the addition or removal of break containers.

> http://libssh2.org/patches/true_labeled_break.diff

> Usage:

> while FOO ($condition) {
>     /* statements */
>     break FOO;
>     /* more statements */
> }

> Or a stacked example:

> for FOO(;;) {
>     while BAR (true) {
>         foreach BAZ ($arr as $val) {
>             switch Foof ($value) {
>                 default:
>                     do Plop {
>                         break FOO;
>                     } while (false);
>             }
>         }
>     }
> }

> Notes on this implementation:

> * Labels can't be repeated in an ancestral line.  For example, the parser
> will throw an ERROR on the following:
> while FOO(true) {
>     while FOO(true) {
>         break FOO;
>     }
> }

> * Labels can be repeated by siblings.  I'm not married to this, and it
> certainly has WTF potential.  This behavior is easily modified to throw an
> error.  I left it permissable because there was no technical reason to
> disallow it.  For example, the following is okay:
> while FOO(true) {
>     break;
> }
> while FOO(true) {
>     break FOO;
> }

> * Labeled breaks also apply to continue;  For example:
> foreach FOO($arr as $key => $val) {
>     if ($key % 2) continue FOO;
>     if (empty(%key)) break FOO;
> }




Best regards,
 Marcus

---

## #20866 — Pierre — 2005-11-30T02:21:16+00:00

URL: https://externals.io/message/20863#20866 · In reply to: #20865

On Wed, 30 Nov 2005 02:52:59 +0100
helly@php.net (Marcus Boerger) wrote:

> Hello Sara,
> 
>   nice work, clean patch, good solution - thanks! what more can one
> say?

commit? :)

--Pierre

---

## #20867 — Sara Golemon — 2005-11-30T02:39:55+00:00

URL: https://externals.io/message/20863#20867 · In reply to: #20866

> > […]
>
> commit? :)
>
Oh how you both love to tease me :p

It occured to me on the way onto the train that this construct doesn't need 
pass_two().  When I get home to more bandwidth I'll cook up a simplified 
version that resolves break distance in zend_do_brk_cont() and frees the 
labels in do_end_loop().

-Sara

---

## #20869 — Ilia Alshanetsky — 2005-11-30T02:41:26+00:00

URL: https://externals.io/message/20863#20869 · In reply to: #20863

I guess I fall into Group B, and I must say that I'd prefer either to
see goto/jump like construct or nothing at all. Be it a crippled
goto/jump or labeled breaks. So, my vote is a -1.

Ilia

---

## #20868 — Sara Golemon — 2005-11-30T02:43:47+00:00

URL: https://externals.io/message/20863#20868 · In reply to: #20864

> Hello, I represent group B (not in any way officially or anything else
> that might give my words an iota of weight), but I (*cough cough*) WE
> think that the above break system would make a terrible system for
> finite state machines.
>
Good, 'cause that's not its purpose.  This doesn't supplant GOTO or preclude 
it.  This is a different topic about a different feature which just happens 
to touch on SOME similar talking points.

> Additionally at this time I'd like to make clear that we are in support
> for full uncrippled break WITHIN scope. Group A can feel free to travel
> to the burning fires of hell and have a barbecue, and group C should
> join us so that at least they get what they want as a subset.
>
Lead on the charge good sir... lead on.

> As an aside, from what I've read, the multitude were in favour of
> unrestricted goto. Quite a few were in favour of none at all (but not as
> many as in group B) and those in favour of none at all had a large
> subset that were in favour of unrestricted goto in the event that group
> B should get their way :)
>
Not to put too fine a point on it, but there's a limited subset of the 
voices on this list that carry the weight needed to push a feature like goto 
into the engine.  Amongst those voices there is a much less decisive quorum.

-Sara

---

## #20870 — Sara Golemon — 2005-11-30T04:17:43+00:00

URL: https://externals.io/message/20863#20870 · In reply to: #20867

> It occured to me on the way onto the train that this construct doesn't 
> need pass_two().  When I get home to more bandwidth I'll cook up a 
> simplified version that resolves break distance in zend_do_brk_cont() and 
> frees the labels in do_end_loop().
>
Okay, simpler/leaner implementation now available.  The new version only 
touches zend_compile.[ch] and zend_language_parser.y though the 
functionality is the same.

http://libssh2.org/patches/true_labeled_break.diff

-Sara

---

## #20872 — Hannes Magnusson — 2005-11-30T07:27:58+00:00

URL: https://externals.io/message/20863#20872 · In reply to: #20863

Elegant solution, however, I'd prefer while(true) FOO { }.

while FOO(true) {} looks like a function call...


> But first, this word from our sponsor:
> Group A wants anything resembling goto to burn in the fires of hell
> Group B wants full non-crippled goto or nothing at all
> Group C wants partial goto (non-backward jumping) or nothing at all
> Groups B and C both (generally) want it called either GOTO or JUMP, not
> BREAK
>
> Since no group this size will ever come to an agreement on something this
> divisive, I'd like to turn the topic to a completely different language
> feature which (might) please enough people to get a rousing consensus.
>
> Actual labeled breaks.  Not the break+jump that was proposed earlier in the
> guise of a break statement, but an actual straightforward, no funny-business
> labeled break which does no more and no less than the current break N;
> construct, but allows the use of identifier labels rather than numbers which
> may change as the result of the addition or removal of break containers.
>
> http://libssh2.org/patches/true_labeled_break.diff
>
> Usage:
>
> while FOO ($condition) {
>     /* statements */
>     break FOO;
>     /* more statements */
> }
>
> Or a stacked example:
>
> for FOO(;;) {
>     while BAR (true) {
>         foreach BAZ ($arr as $val) {
>             switch Foof ($value) {
>                 default:
>                     do Plop {
>                         break FOO;
>                     } while (false);
>             }
>         }
>     }
> }
>
> Notes on this implementation:
>
> * Labels can't be repeated in an ancestral line.  For example, the parser
> will throw an ERROR on the following:
> while FOO(true) {
>     while FOO(true) {
>         break FOO;
>     }
> }
>
> * Labels can be repeated by siblings.  I'm not married to this, and it
> certainly has WTF potential.  This behavior is easily modified to throw an
> error.  I left it permissable because there was no technical reason to
> disallow it.  For example, the following is okay:
> while FOO(true) {
>     break;
> }
> while FOO(true) {
>     break FOO;
> }
>
> * Labeled breaks also apply to continue;  For example:
> foreach FOO($arr as $key => $val) {
>     if ($key % 2) continue FOO;
>     if (empty(%key)) break FOO;
> }

---

## #20873 — Ron Korving — 2005-11-30T07:39:47+00:00

URL: https://externals.io/message/20863#20873 · In reply to: #20872

I loved Joao Cruz Morais idea of using the 'as' keyword in this:

while (true) as outer_cycle {
  $i = 0;
  while (true)
    if($i++ == 10) break outer_cycle;
}

I think it's really clear and with this syntax you (at least in my opinion) 
kinda loose the feeling of needing all caps for a label name. Somehow it 
feels less like a constant. This is absolutely personal though, and could be 
just between my ears, not yours... I just love this syntax ;)

Ron



"Hannes Magnusson" <hannes.magnusson@gmail.com> schreef in bericht 
news:7f3ed2c30511292327p1ffae378n9c2bfb01bdb333d3@mail.gmail.com...
Elegant solution, however, I'd prefer while(true) FOO { }.

while FOO(true) {} looks like a function call...


> But first, this word from our sponsor:
> Group A wants anything resembling goto to burn in the fires of hell
> Group B wants full non-crippled goto or nothing at all
> Group C wants partial goto (non-backward jumping) or nothing at all
> Groups B and C both (generally) want it called either GOTO or JUMP, not
> BREAK
>
> Since no group this size will ever come to an agreement on something this
> divisive, I'd like to turn the topic to a completely different language
> feature which (might) please enough people to get a rousing consensus.
>
> Actual labeled breaks.  Not the break+jump that was proposed earlier in 
> the
> guise of a break statement, but an actual straightforward, no 
> funny-business
> labeled break which does no more and no less than the current break N;
> construct, but allows the use of identifier labels rather than numbers 
> which
> may change as the result of the addition or removal of break containers.
>
> http://libssh2.org/patches/true_labeled_break.diff
>
> Usage:
>
> while FOO ($condition) {
>     /* statements */
>     break FOO;
>     /* more statements */
> }
>
> Or a stacked example:
>
> for FOO(;;) {
>     while BAR (true) {
>         foreach BAZ ($arr as $val) {
>             switch Foof ($value) {
>                 default:
>                     do Plop {
>                         break FOO;
>                     } while (false);
>             }
>         }
>     }
> }
>
> Notes on this implementation:
>
> * Labels can't be repeated in an ancestral line.  For example, the parser
> will throw an ERROR on the following:
> while FOO(true) {
>     while FOO(true) {
>         break FOO;
>     }
> }
>
> * Labels can be repeated by siblings.  I'm not married to this, and it
> certainly has WTF potential.  This behavior is easily modified to throw an
> error.  I left it permissable because there was no technical reason to
> disallow it.  For example, the following is okay:
> while FOO(true) {
>     break;
> }
> while FOO(true) {
>     break FOO;
> }
>
> * Labeled breaks also apply to continue;  For example:
> foreach FOO($arr as $key => $val) {
>     if ($key % 2) continue FOO;
>     if (empty(%key)) break FOO;
> }

---

## #20876 — Dmitry Stogov — 2005-11-30T08:02:53+00:00

URL: https://externals.io/message/20863#20876 · In reply to: #20863

Hi Sara,

This "break LABEL" construct does exactly the same as "break NUM",

Also I don't like syntax for loops that you suggested.
I prefer "LABEL: while(1) {...}" instead of while LABEL (1) {...}".

This construct has logic and make sense, but I am not sure that we should
incrise complication of PHP compiler without any serious benefits.
Readability is the only one benefit of this patch.

May be I missed something? I didn't look into patch deep.

Thanks. Dmitry.

> -----Original Message-----
> From: Sara Golemon [mailto:pollita@php.net] 
> Sent: Wednesday, November 30, 2005 4:41 AM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Labeled Break (nothing at all whatsoever 
> to do with GOTO)
> 
> 
> But first, this word from our sponsor:
> Group A wants anything resembling goto to burn in the fires 
> of hell Group B wants full non-crippled goto or nothing at 
> all Group C wants partial goto (non-backward jumping) or 
> nothing at all Groups B and C both (generally) want it called 
> either GOTO or JUMP, not BREAK
> 
> Since no group this size will ever come to an agreement on 
> something this divisive, I'd like to turn the topic to a 
> completely different language feature which (might) please 
> enough people to get a rousing consensus.
> 
> Actual labeled breaks.  Not the break+jump that was proposed 
> earlier in the guise of a break statement, but an actual 
> straightforward, no funny-business labeled break which does 
> no more and no less than the current break N; construct, but 
> allows the use of identifier labels rather than numbers which 
> may change as the result of the addition or removal of break 
> containers.
> 
> http://libssh2.org/patches/true_labeled_break.diff
> 
> Usage:
> 
> while FOO ($condition) {
>     /* statements */
>     break FOO;
>     /* more statements */
> }
> 
> Or a stacked example:
> 
> for FOO(;;) {
>     while BAR (true) {
>         foreach BAZ ($arr as $val) {
>             switch Foof ($value) {
>                 default:
>                     do Plop {
>                         break FOO;
>                     } while (false);
>             }
>         }
>     }
> }
> 
> Notes on this implementation:
> 
> * Labels can't be repeated in an ancestral line.  For 
> example, the parser will throw an ERROR on the following: 
> while FOO(true) {
>     while FOO(true) {
>         break FOO;
>     }
> }
> 
> * Labels can be repeated by siblings.  I'm not married to 
> this, and it certainly has WTF potential.  This behavior is 
> easily modified to throw an error.  I left it permissable 
> because there was no technical reason to disallow it.  For 
> example, the following is okay: while FOO(true) {
>     break;
> }
> while FOO(true) {
>     break FOO;
> }
> 
> * Labeled breaks also apply to continue;  For example:
> foreach FOO($arr as $key => $val) {
>     if ($key % 2) continue FOO;
>     if (empty(%key)) break FOO;
> }

---

## #20878 — Sebastian Kugler — 2005-11-30T08:15:38+00:00

URL: https://externals.io/message/20863#20878 · In reply to: #20873

> I loved Joao Cruz Morais idea of using the 'as' keyword in this:
>
> while (true) as outer_cycle {
>   $i = 0;
>   while (true)
>     if($i++ == 10) break outer_cycle;
> }

Me too - it's so stunningly obvious to understand at first sight,
compared to while LABEL (cond) {

Don't know of course if there are technical reasons against this
proposal, just my 2 cents from the user's perspective.

--Sebastian

---

## #20879 — Hannes Magnusson — 2005-11-30T08:25:23+00:00

URL: https://externals.io/message/20863#20879 · In reply to: #20876

IMO labeld breaks are *alot* more readable then break NUM;


> Hi Sara,
>
> This "break LABEL" construct does exactly the same as "break NUM",
>
> Also I don't like syntax for loops that you suggested.
> I prefer "LABEL: while(1) {...}" instead of while LABEL (1) {...}".
>
> This construct has logic and make sense, but I am not sure that we should
> incrise complication of PHP compiler without any serious benefits.
> Readability is the only one benefit of this patch.
>
> May be I missed something? I didn't look into patch deep.
>
> Thanks. Dmitry.
>
> > […]

---

## #20881 — Jani Taskinen — 2005-11-30T08:42:25+00:00

URL: https://externals.io/message/20863#20881 · In reply to: #20863

I don't care what kind of GOTO I get as long as I get one.
     Right now I only see need for the forward jumping version,
     but I don't mind if you could jump backwards too. :)

     And I also want VETO on each and every bug report about it. :)
     If anyone dares to report a bug with goto in it -> automatic bogus.

     We make it work for the simple usage it's meant for and if someone
     uses it wrong, too bad. :)

     And the labeled breaks you suggest now can burn in hell!

     --Jani




>
> But first, this word from our sponsor:
> Group A wants anything resembling goto to burn in the fires of hell
> Group B wants full non-crippled goto or nothing at all
> Group C wants partial goto (non-backward jumping) or nothing at all
> Groups B and C both (generally) want it called either GOTO or JUMP, not
> BREAK
>
> Since no group this size will ever come to an agreement on something this
> divisive, I'd like to turn the topic to a completely different language
> feature which (might) please enough people to get a rousing consensus.
>
> Actual labeled breaks.  Not the break+jump that was proposed earlier in the
> guise of a break statement, but an actual straightforward, no funny-business
> labeled break which does no more and no less than the current break N;
> construct, but allows the use of identifier labels rather than numbers which
> may change as the result of the addition or removal of break containers.
>
> http://libssh2.org/patches/true_labeled_break.diff
>
> Usage:
>
> while FOO ($condition) {
>    /* statements */
>    break FOO;
>    /* more statements */
> }
>
> Or a stacked example:
>
> for FOO(;;) {
>    while BAR (true) {
>        foreach BAZ ($arr as $val) {
>            switch Foof ($value) {
>                default:
>                    do Plop {
>                        break FOO;
>                    } while (false);
>            }
>        }
>    }
> }
>
> Notes on this implementation:
>
> * Labels can't be repeated in an ancestral line.  For example, the parser
> will throw an ERROR on the following:
> while FOO(true) {
>    while FOO(true) {
>        break FOO;
>    }
> }
>
> * Labels can be repeated by siblings.  I'm not married to this, and it
> certainly has WTF potential.  This behavior is easily modified to throw an
> error.  I left it permissable because there was no technical reason to
> disallow it.  For example, the following is okay:
> while FOO(true) {
>    break;
> }
> while FOO(true) {
>    break FOO;
> }
>
> * Labeled breaks also apply to continue;  For example:
> foreach FOO($arr as $key => $val) {
>    if ($key % 2) continue FOO;
>    if (empty(%key)) break FOO;
> }
>
>

-- 
Give me your money at @ <http://pecl.php.net/wishlist.php/sniper>
Donating money may make me happier and friendlier for a limited period!
Death to all 4 letter abbreviations starting with P!

---

## #20882 — David M. Patterson — 2005-11-30T08:47:44+00:00

URL: https://externals.io/message/20863#20882 · In reply to: #20879

Not only are labeled breaks more readable, they are far more maintainable,
especially when nested. With break NUM, you have to change the NUMs
every time you change the nesting. I've shot myself in the foot several
times
that way.
Just my two cents as a long-time PHP user
Dave

Hannes Magnusson  said:

> IMO labeld breaks are *alot* more readable then break NUM;


> Hi Sara,
>
> This "break LABEL" construct does exactly the same as "break NUM",
>
> Also I don't like syntax for loops that you suggested.
> I prefer "LABEL: while(1) {...}" instead of while LABEL (1) {...}".
>
> This construct has logic and make sense, but I am not sure that we should
> incrise complication of PHP compiler without any serious benefits.
> Readability is the only one benefit of this patch.
>
> May be I missed something? I didn't look into patch deep.
>
> Thanks. Dmitry.
>
> > […]

---

## #20883 — Bart de Boer — 2005-11-30T09:11:11+00:00

URL: https://externals.io/message/20863#20883 · In reply to: #20863

Sara++  :)

Although I prefer BAR:while (This would go better with goto if someone 
would want to implement that some day.) I'd settle for while BAR since I 
don't care about goto anyway.

So:

foreach BAZ ($arr as $val) +1


BAZ: foreach ($arr as $val) +2


foreach as BAZ ($arr as $val) -2 ('as' can be a bit confusing here)




Sara Golemon wrote:
> But first, this word from our sponsor:
> Group A wants anything resembling goto to burn in the fires of hell
> Group B wants full non-crippled goto or nothing at all
> Group C wants partial goto (non-backward jumping) or nothing at all
> Groups B and C both (generally) want it called either GOTO or JUMP, not
> BREAK
> 
> Since no group this size will ever come to an agreement on something this
> divisive, I'd like to turn the topic to a completely different language
> feature which (might) please enough people to get a rousing consensus.
> 
> Actual labeled breaks.  Not the break+jump that was proposed earlier in the
> guise of a break statement, but an actual straightforward, no funny-business
> labeled break which does no more and no less than the current break N;
> construct, but allows the use of identifier labels rather than numbers which
> may change as the result of the addition or removal of break containers.
> 
> http://libssh2.org/patches/true_labeled_break.diff
> 
> Usage:
> 
> while FOO ($condition) {
>     /* statements */
>     break FOO;
>     /* more statements */
> }
> 
> Or a stacked example:
> 
> for FOO(;;) {
>     while BAR (true) {
>         foreach BAZ ($arr as $val) {
>             switch Foof ($value) {
>                 default:
>                     do Plop {
>                         break FOO;
>                     } while (false);
>             }
>         }
>     }
> }
> 
> Notes on this implementation:
> 
> * Labels can't be repeated in an ancestral line.  For example, the parser
> will throw an ERROR on the following:
> while FOO(true) {
>     while FOO(true) {
>         break FOO;
>     }
> }
> 
> * Labels can be repeated by siblings.  I'm not married to this, and it
> certainly has WTF potential.  This behavior is easily modified to throw an
> error.  I left it permissable because there was no technical reason to
> disallow it.  For example, the following is okay:
> while FOO(true) {
>     break;
> }
> while FOO(true) {
>     break FOO;
> }
> 
> * Labeled breaks also apply to continue;  For example:
> foreach FOO($arr as $key => $val) {
>     if ($key % 2) continue FOO;
>     if (empty(%key)) break FOO;
> }

---

## #20884 — Ron Korving — 2005-11-30T09:24:14+00:00

URL: https://externals.io/message/20863#20884 · In reply to: #20883

I'd say:

foreach ($arr as $val) as foo
{
  if (true)
    break foo;
}

I don't like the idea at all that labeled breaks are in any way connected to 
'goto' usage. It's my opinion that the two can coexist without a problem, 
and that's how I would prefer to see it being used.

Besides, BAR:while () { } would not do well with a future 
goto-implementation, because that would mean it would jump to the beginning 
of the loop, and not out of the loop. Maybe you mean to say that labels for 
goto and break can exist in the same collection, but I wouldn't be a fan of 
that at all.

Semantically, 'goto' behavior is very different from break-behavior. With a 
break I expect to leave a certain construct that has a certain name, with 
goto I expect to jump to the line of code that was labeled with a name. I 
think the usage is different enough not to want those labels to be the same 
kind of things. Maybe other people disagree, but my point is that the 
difference in semantics is really something to consider.

When you make break-labels the same as goto-labels, I would find this a bit 
weird to read:

FOO: while (true)
{
  ...
}

Will it be used for breaking out of the loop or for jumping to the loop? 
Should I expect a goto statement somewhere in this file?

- Ron



"Bart de Boer" <bart@mediawave.nl> schreef in bericht 
news:AA.64.14828.88C6D834@pb1.pair.com...
> Sara++  :)
>
> Although I prefer BAR:while (This would go better with goto if someone 
> would want to implement that some day.) I'd settle for while BAR since I 
> don't care about goto anyway.
>
> So:
>
> foreach BAZ ($arr as $val) +1
>
>
> BAZ: foreach ($arr as $val) +2
>
>
> foreach as BAZ ($arr as $val) -2 ('as' can be a bit confusing here)

---

## #20888 — Hartmut Holzgraefe — 2005-11-30T09:36:38+00:00

URL: https://externals.io/message/20863#20888 · In reply to: #20869

Ilia Alshanetsky wrote:
> I guess I fall into Group B, and I must say that I'd prefer either to
> see goto/jump like construct or nothing at all. Be it a crippled
> goto/jump or labeled breaks. So, my vote is a -1.

think of not in the context of GOTO but as in
'break _number_;" finally done right'

-- 
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

---

## #20889 — Hartmut Holzgraefe — 2005-11-30T09:39:59+00:00

URL: https://externals.io/message/20863#20889 · In reply to: #20873

Ron Korving wrote:
> I loved Joao Cruz Morais idea of using the 'as' keyword in this:
> 
> while (true) as outer_cycle {
>   $i = 0;
>   while (true)
>     if($i++ == 10) break outer_cycle;
> }

might become a bit confusing with

   foreach ($array as $val) as someloop {

but that aside i like the syntax :)


-- 
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

---

## #20890 — Bart de Boer — 2005-11-30T09:45:48+00:00

URL: https://externals.io/message/20863#20890 · In reply to: #20884

I wasn't thinking about goto or break. I was thinking about *labels* and 
using them in a consistent manner with PHP.

For example:

while (cond) {
   LABEL:
   while (cond) {
     if (cond) {
       break LABEL;
     } else {
       some_command OTHERLABEL;
     }
   }
}
OTHERLABEL:


Or Sara's way:

while (cond) {
   while LABEL (cond) {
     if (cond) {
       break LABEL;
     } else {
       some_command OTHERLABEL;
     }
   }
}
OTHERLABEL;


In the last example. Would OTHERLABEL; be possible technically? Say, 
*if* we'd want to use it this way some day? If so, I'll give it +2.




Ron Korving wrote:
> I'd say:
> 
> foreach ($arr as $val) as foo
> {
>   if (true)
>     break foo;
> }
> 
> I don't like the idea at all that labeled breaks are in any way connected to 
> 'goto' usage. It's my opinion that the two can coexist without a problem, 
> and that's how I would prefer to see it being used.
> 
> Besides, BAR:while () { } would not do well with a future 
> goto-implementation, because that would mean it would jump to the beginning 
> of the loop, and not out of the loop. Maybe you mean to say that labels for 
> goto and break can exist in the same collection, but I wouldn't be a fan of 
> that at all.
> 
> Semantically, 'goto' behavior is very different from break-behavior. With a 
> break I expect to leave a certain construct that has a certain name, with 
> goto I expect to jump to the line of code that was labeled with a name. I 
> think the usage is different enough not to want those labels to be the same 
> kind of things. Maybe other people disagree, but my point is that the 
> difference in semantics is really something to consider.

---

## #20893 — Stanislav Malyshev — 2005-11-30T09:50:49+00:00

URL: https://externals.io/message/20863#20893 · In reply to: #20863

SG>>Actual labeled breaks.  Not the break+jump that was proposed earlier in the

I think the idea is OK, though I don't like a syntax. There is a standard 
for/while syntax which is used by a lot of procedural languages, and I see 
no reason to break it. I see nothing wrong with using FOO: for label.

SG>>* Labels can be repeated by siblings.  I'm not married to this, and it

I don't think this is really needed, though it's doable and has some logic 
in it (after all, once the labelled block ends, the label is not longer 
existing).

SG>>* Labeled breaks also apply to continue;  For example:

yes, I think it's a good way to do it.

-- 
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

---

## #20894 — Hartmut Holzgraefe — 2005-11-30T10:12:29+00:00

URL: https://externals.io/message/20863#20894 · In reply to: #20893

Stanislav Malyshev wrote:
> SG>>* Labeled breaks also apply to continue;  For example:
> 
> yes, I think it's a good way to do it.

oh, totally forgot about that, another strong reason for having
it in parallel to any GOTO solution we come up with


-- 
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

---

## #20898 — Sara Golemon — 2005-11-30T15:08:23+00:00

URL: https://externals.io/message/20863#20898 · In reply to: #20876

> This "break LABEL" construct does exactly the same as "break NUM",
>
> May be I missed something? I didn't look into patch deep.
>
Your take is spot-on.  This isn't an extension of functionality, just a 
"numbered breaks with a name" which is something I've heard requested from 
several corners (including @zend.com) as a "wouldn't it be nice..."

> Also I don't like syntax for loops that you suggested.
> I prefer "LABEL: while(1) {...}" instead of while LABEL (1) {...}".
>
I agree that the positioning of the label has an inherent ugliness to it. 
I avoided "LABEL: while (1) { }" however, in order to avoid conflicting with 
and complicating the GOTO discussion.  Since (if goto was added as well) 
this syntax could create an ambiguity in what the label means.

Since you'd like the label to be moved out of zend_brk_cont_element, then 
perhaps we can allow this syntax to pull double duty...
LABEL: whlie(1) {
  break LABEL; <-- el->brk
  continue LABEL;  <-- el->cont
  goto LABEL;  <-- opline->u.opline_num
  break OTHERLABEL; <-- error
  continue OTHERLABEL; <-- error
  goto OTHERLABEL; <-- opline->u.opline_num
}
OTHERLABEL:
nonBreakContainerStatement();

> This construct has logic and make sense, but I am not sure that we should
> incrise complication of PHP compiler without any serious benefits.
> Readability is the only one benefit of this patch.
>
So the question is:  How serious is the gain in readability/maintainability?

-Sara

---

## #20900 — Bart de Boer — 2005-11-30T16:13:55+00:00

URL: https://externals.io/message/20863#20900 · In reply to: #20898

Sounds good from a syntax perspective... :)


Sara Golemon wrote:
> > […]
> Your take is spot-on.  This isn't an extension of functionality, just a 
> "numbered breaks with a name" which is something I've heard requested 
> from several corners (including @zend.com) as a "wouldn't it be nice..."
> 
> > […]
> I agree that the positioning of the label has an inherent ugliness to 
> it. I avoided "LABEL: while (1) { }" however, in order to avoid 
> conflicting with and complicating the GOTO discussion.  Since (if goto 
> was added as well) this syntax could create an ambiguity in what the 
> label means.
> 
> Since you'd like the label to be moved out of zend_brk_cont_element, 
> then perhaps we can allow this syntax to pull double duty...
> LABEL: whlie(1) {
>  break LABEL; <-- el->brk
>  continue LABEL;  <-- el->cont
>  goto LABEL;  <-- opline->u.opline_num
>  break OTHERLABEL; <-- error
>  continue OTHERLABEL; <-- error
>  goto OTHERLABEL; <-- opline->u.opline_num
> }
> OTHERLABEL:
> nonBreakContainerStatement();
> 
> > […]
> So the question is:  How serious is the gain in 
> readability/maintainability?
> 
> -Sara

---

## #20901 — Jochem Maas — 2005-11-30T16:17:39+00:00

URL: https://externals.io/message/20863#20901 · In reply to: #20898

Sara Golemon wrote:

...

> Your take is spot-on.  This isn't an extension of functionality, just a 
> "numbered breaks with a name" which is something I've heard requested 
> from several corners (including @zend.com) as a "wouldn't it be nice..."
> 

I wonder if the need for labelled breaks/continues might dissapear (in practice)
if those people who could most do with them are given 'goto' (without the
no-go-backwards limitation) instead? Everytime I see heavily nested 'break n'
statements it makes me wince and the only times there seems to be no
real/decent alternative to such nesting is when building some kind of
state machine ... state machines being one of the few concrete examples
to support the implementation of 'goto' in the first place, no?

...

> Since you'd like the label to be moved out of zend_brk_cont_element, 
> then perhaps we can allow this syntax to pull double duty...

devils advocate:
what happens when I want to place a 'goto' label just before a while or foreach
loop (upon which I haven't put a label)? I ask because I assume that the following 2
statements should be identical no:?

<?php
LABEL: while(1) {
/* ..etc */
?>

<?php
LABEL:
while(1) {
/* ..etc */
?>



> LABEL: whlie(1) {
>  break LABEL; <-- el->brk
>  continue LABEL;  <-- el->cont
>  goto LABEL;  <-- opline->u.opline_num
>  break OTHERLABEL; <-- error
>  continue OTHERLABEL; <-- error
>  goto OTHERLABEL; <-- opline->u.opline_num
> }
> OTHERLABEL:
> nonBreakContainerStatement();
> 
> > […]
> So the question is:  How serious is the gain in 
> readability/maintainability?
> 
> -Sara

---

Next page: https://externals.io/message/20863.md?page=2