ENIGMA Forums
Contributing to ENIGMA => Proposals => Topic started by: Josh @ Dreamland on September 08, 2012, 04:47:37 pm
-
for (int i = 0; i < 10; ++i) {
for (int j = 0; j < 10; ++j) {
if (target[i][j])
break; // FUCK!
}
}
Named Loops:
HOLYFUCKIDONTKNOWWHATTONAMETHISLOOP: for (int i = 0; i < 10; ++i) {
for (int j = 0; j < 10; ++j) {
if (target[i][j])
break HOLYFUCKIDONTKNOWWHATTONAMETHISLOOP; // yay?
}
}
Numbered breaks:
for (int i = 0; i < 10; ++i) {
for (int j = 0; j < 10; ++j) {
if (target[i][j])
break 2; // (Y)
}
}
-
I vote named loops primarily because with numbers, the off-by-one would confuse me.
Although I guess it makes sense - break 1 breaks the first loop, break 2 breaks out of the second loop, break 0 does nothing.
-
While "both" was originally a joke, I actually think I might do it. My main aversion to it was that it would make goto labels ambiguous, but in the end, (1) do we really want goto, and (2) why can't a loop name also be a label?
It would be simple to just warn on [snip]break 1;[/snip]. Did I mention I'm adding warnings?
-
Having thought about it I now vote break << 1; break << 2; to break one loop back, two loops back.
I think adding both is over-kill and might be confusing, in fact named loops makes things more confusing by itself in that it will make it harder to read other people's code whereas numbered breaks can be universally understood.
-
That's pretty ugly, and it doesn't match other languages, so newcomers couldn't really guess it. If we're going to have them learn something new, it should be that the number after break is the total number of loops to exit, not the additional number.
People are really used to named loops, too. We'll let the userbase decide.
-
What warnings? For debug?
And I also have some problems with understanding labeled breaks. I checked some JS examples and it seemed that break 2; in Josh's example would stop both loops, but break label; in that example would break the inner loop and go to the outer loop. Although maybe the example I saw was just bs.
-
That is what [snip=edl]continue loop;[/snip] would do. Same as [snip=edl]continue 2;[/snip].
-
I voted named loops because it's less confusing, more intuitive and less error-prone.
Besides, it's the way Java does it so there are already precedents showing it can work.
Regarding the "error prone" part, imagine if you replaced that if case with a switch case. Then you'd have to change "break 2" to "break 3". Would you remember? That would be a pretty messy bug to track down. With named loops, there is no such problem.
Regarding warnings to "break 1". Why even allow it in the first place? Just ban it with a compile error. Problem solved. One less horrible feature to test.
The question to ask about "numbered breaks" is not "can we add it easily?", which I have no doubt you can if you can also do named loops. The real question is "what would this improve?". I can not think of any situation where numbered breaks would beat named breaks.
BTW: Just call the loop "outer_loop: for(...)"
-
Regarding warnings to "break 1".
Is that the warning Josh was talking about? And why would this even need a warning? Was is invalid about that statement?
-
It is the same as break, so why use it?
-
Yet one more reason to avoid numbered breaks: Some people might expect "start at 0" while others will expect "start at 1".
-
I'd warn/error on break 0, too.
It's easier to to read break 2, in my opinion; even if you're in a huge nested loop, you have an idea of how many loops you're in, whereas you can easily forget what a loop is named. Granted, you can assume it breaks the big one or huge one based on context, but with break 3, you know it's breaking all of them.
-
Well:
z_loop: for (int z = 0; z < 100; ++z) {
y_loop: for (int y = 0; y < 100; ++y) {
x_loop: for (int x = 0; x < 100; ++x) {
break z_loop;
}
}
}
and
instance_loop: foreach (auto instance : instances) {
adjacent_instances_loop: foreach (auto adjacent : instance.adjacent_instances()) {
break instance_loop;
}
}
Seems pretty clear to me.
Frankly, I'd generally avoid using integers for anything that can be reasonably named, but whatever.
Just remember: more features mean more test cases.
And regarding test cases, don't forget to add mixed loops/switch cases to your test suite.
-
I see both sides. I'm pretty sure I'll end up doing both; the mechanism that handles the double break will be the same, so the difference between the two implementations C++-side will be in identifying the loop to which the user is referring.
-
If you have to do it, use named loops.
It looks like a good companion to goto+label, I think it's a nice fit for a pasta lover. :D
-
None. If the programming was more function oriented, this wouldn't matter ;)