Remove block jumping restrictions on Goto and GoSub

[Raccoon]

So I know this sounds weird and the style of coding will upset anybody with an inkling proper top-down coding, but, what I'm requesting isn't entirely unuseful or without merit and precedence.

Presently the commands Goto and GoSub prohibit jumping in and out of functions to labels that exist inside a different "block" enclosure.
The restrictions are on the Goto and GoSub commands themselves, and not inherent or problematic in the scripting engine, making the restrictions arbitrary.

Presently, any callbacks and hooks that utilize labels CAN jump into functions without restriction, and it's sometimes useful.

Given that labels are Global in scope, there's no risk of confusion which label is intended.

Jumping into a function can allow you to alter the value of Static variables within that function, so you can avoid using global variables... and other goofy things.

#include libraries that require labels should be encapsulated in a dummy function to prevent early execution and termination of the auto-execute portion of the script.

Decorum: Arguments of "You should never use Goto or GoSub" are automatically invalid and off-topic by the very existence of their syntax. I'm not bound to such rules.

[swagfag]

huuuuuuuuh??
can u show an example where something can be achieved through no other means than using a GoTo to jump inside of a block?
i dont know how u figured the restrictions were arbitrary. i dont think they are. consider this:

Code: Select all

str := "abc123"

Loop Parse, str
{
	Target:
	MsgBox % A_LoopField
}

Goto Target

what is the value of A_LoopField when u GoTo from the outside(provided u could)?
if u want to avoid using globals, there are other ways to do so(although i dont consider static one of them)

[Raccoon]

swagfag: In your example code, the expected behavior would be to Msgbox an undefined A_LoopField, fall through the closing brace, and then Goto Target again. Unless A_LoopField stays defined after the final iteration of Loop Parse's first round.

Actually, I would extend my original request not only to Goto and GoSub, but Hotkey and Hotstring definitions as well since they are just glorified Sub Labels themselves behind the scenes, and are also prohibited from being placed inside functions and other blocks willy-nilly.

A 'timer, label' and 'onexit, label' can can Goto Target in your example, and the world doesn't end. Making it an "arbitrary restriction" by definition.

I would lift the restriction and move the error msg to the #Warn directive.

[just me]

Hi Racoon,

would you please provide some real-life examples showing where you would find it useful?

[Raccoon]

Here's a simplified example; Sure there are other approaches for this example. I'm not saying there aren't.
Not tested, so if I make an obvious bug, forgive it.

Code: Select all

#If GetKeyState("ScrollLock","T")

Up::
Down::
Left::
Right::
hotkey_RapidFireMacro()
{
  Static delay := 100, stop := false
  Loop
  {
    Send % A_ThisHotkey
    Sleep delay
  } Until (stop)
  stop := false
  Return

  PgUp:: delay -= 100
  PgDn:: delay += 100
  End:: stop := true
}

#if ; End If Scrollock

[swagfag]

man, im not convinced. the counter argument isnt "goto = bad", its "does sinking dev time into rearranging the parser yield a worthwhile practical benefit"

Presently, any callbacks and hooks that utilize labels CAN jump into functions without restriction, and it's sometimes useful.
A 'timer, label' and 'onexit, label' can can Goto Target in your example, and the world doesn't end. Making it an "arbitrary restriction" by definition.

A_LoopField will be undefined. the restrictions arent at all arbitrary. the restrictions are there to prevent exactly this scenario where ure forced to operate in a halfway-initialized state. think about break or continue. when u jump to some part in a loop, how should those behave? are they aware theyre in a loop? are they simply ignored? what a pain it would be to have to document "keyword X does Y, unless u WentTo it, in which case it does Z", not to mention having to remain cognizant of the fact.

what about functions? suppose u start setting vars. are they aware theyre in a function? are they local to it or do they spill into the global scope?

Presently, any callbacks and hooks that utilize labels CANNOT jump without restrictions. the restriction is "no closing brace may be encountered", at which point "the world"(current thread) does end

what a nightmare

Code: Select all

greet(greeting, name) {
    Target:
    MsgBox % greeting ", " name "!"
}

MsgBox % "autoexec end"
q::goto Target ; executes both msgboxes

is there even any other language that allows what ure proposing, barring asm?

i aint saying there aint any legitimate uses for goto, because there totally are - like for the purposes of errorhandling for instance. actually, i probably shouldnt have used plural here, because its about the only legitimate application of goto i can think of...

---

ur example in v2, without goto:

Code: Select all

Up::
Down::
Left::
Right::
fire() {
	static init := make_hotkeys()
		, delay := 100

	ToolTip(delay)

	make_hotkeys() {
		Hotkey("PgUp", () => delay -= 100)
		Hotkey("PgDown", () => delay += 100)
	}
}

[Raccoon]

I'm not saying that anything needs to be changed to how AHK interprets these things. It's WAAY better if break or continue behave in strange and sexy ways when you introduce a jump point, the same way you discover strange and sexy coding strategies in basic and assembly and a myriad of other languages. All I am asking is that the prohibitions be removed unless #Warn is present.

The same way that strange and sexy behavior happens if you don't declare your variables, and other such things that #Warn covers.