14 replies to this topic

[stevenp]

Break [, LoopLabel][AHK_L 59+]: If specified, LoopLabel identifies which loop this statement should apply to; either by label name or numeric nesting level. If omitted or 1, this statement applies to the innermost loop in which it is enclosed. LoopLabel must be a constant value; i.e. variables and expressions are not supported.

But there is no mentioning that the Loop should start right after the Label.
Even adding a declaration between the label and the loop structure leads to error.
This behaviour should be denoted in the help file, Lexikos?

[Lexikos]

I'd thought it obvious that only a label pointing at the loop "identifies" it, but I see no problem with adding:

If a label is specified, it must point directly at a loop command.

Btw,

The target of a label is the next line of executable code.
Source: Labels

However, there doesn't seem to be a link to that page from Break/Continue.

[stevenp]

Executable code includes commands, assignments, expressions and blocks

assignment is also executable code

I'd thought it obvious that only a label pointing at the loop "identifies" it

Why? I think it's obvious to think that when something points to a label it should work similarly to GoTo/GoSub.
When you add a Label, you may not plan to use it as an anchor to a loop structure.

imho, a LoopLabel is a different kind of label, it is not a usual label, and maybe the syntax is also should be different for such anchored labels in future ahk releases.

[Lexikos]

A label, in the strictest and simplest sense, merely points at a single line of code. Nothing more. You seem to have confused the properties of a label with the behaviour of commands which use labels. Even considering only Gosub and Goto, the meaning of a label differs: it could be the beginning of a subroutine, or merely a jump point within the current subroutine. Break and Continue do not execute subroutines or directly jump to the label, so clearly the meaning of the label is different.

[stevenp]

It's already confused in the language.

Even considering only Gosub and Goto, the meaning of a label differs

You're right, a GoSub label is anchored to a return command, that's also a different kind of label, maybe it also should have other syntax, so that editors could Fold such Label-Return blocks.
But why a Break-to-Label doesn't allow nothing else except the loop from which it comes? imho this behaviour should be reconsidered to avoid using GoTo/GoSub when other commands should be after the label

[Lexikos]

that's also a different kind of label, maybe it also should have other syntax,

You missed the point. And no, there shouldn't be many different syntaxes for labels.

imho this behaviour should be reconsidered to avoid using GoTo/GoSub when other commands should be after the label

There's absolutely no reason that the current behaviour would force you to use goto/gosub. Just add another label.

[stevenp]

Just add another label.

That's a good workaround and in that case a GoTo should be used instead of Break, when some code should be added between the label and the loop

[Lexikos]

Did you understand any part of my post?

There is no need to use goto.

sub:  [color=green]; [/color][color=red]DON'T [/color][color=green]use this to identify the loop.[/color]
[color=#666666]var = initialized[/color]
sub's_loop:  [color=green]; Use this. There's no reason to put commands between it and Loop.[/color]
Loop {
    [color=#666666];...[/color]
    Loop {
        [color=#666666];...[/color]
        break sub's_loop
    }
}

This is not a workaround. It is meant to be done this way.

[guest3456]

tangent:
following this thread led me to finally exploring the difference between GoSub and GoTo:

   msgbox, hi

   ;GoSub, mysub
   GoTo, mysub

   msgbox, this is shown when using GoSub, but not when using GoTo

return   ;// end of autoexec


mysub:
   msgbox, mysub
return

[stevenp]

This is not a workaround. It is meant to be done this way.

You just got used to this behavior, that's why you're so offensive. Don't take it too seriously, it's not a religion.

Did you understand any part of my post?

Am I not?

There's a need to use GoTo when some commands should be processed before the loop

label: 
somefunction1()
somefunction2()
Loop {
    ;...
    Loop {
        ;...
        goto label
    }
}

I read help when some problems in the code, and there was no hint about this behavior.
I just wanted to report this for you as I know you are responsible for the help files.
Thanks

[fragman]

GoTo isn't really ever needed. Most programmers will advise you not to use it because it makes readability worse. There are some cases where it can be useful but those are rare. I may have used it 5 times or so in a >30k lines program.
If yiou ask me the label functionality of the break/continue commands aren't really needed, the numeric method is better IMO.

[Lexikos]

I'm fairly certain that I misunderstood you. I just don't know which parts...

There's a need to use GoTo when some commands should be processed before the loop

You previously stated that "this behaviour should be reconsidered to avoid using GoTo/GoSub". I will accept that there are situations where goto may be useful, but there doesn't appear to be any way that "reconsidering" the current behaviour will help to avoid those situations. On the contrary - it seems to me that allowing commands between the label and loop would only be useful if the label is also used for some purpose other than break/continue, such as goto.

I read help when some problems in the code, and there was no hint about this behavior.

Other than the example...

[stevenp]

I'm sorry, no need to change anything in the syntax, just a note for this behavior in the help files is enough in case one forgot, or as fragman said, avoid using labels, maybe it's possible by using functions everywhere.

I read help when some problems in the code, and there was no hint about this behavior.

Other than the example...

There's no mention in the example about this rule.

[Lexikos]

I didn't say there was.

and there was no hint about this behavior.