(Windows batch) Goto within if block behaves very strangely

Question

If I take the following Windows batch code snippet and run it:

echo foo
if 1 == 1 (
    echo bar
    goto asdf
    :asdf
    echo baz
) else (
    echo quux
)

The output I would expect is:

foo
bar
baz

But instead I get:

foo
bar
baz
quux

If I comment out the goto asdf line, it gives the output I expect. The echo quux line should never be exectuted, so why is the existence of the goto causing that to happen?

UPDATE: For what it's worth, here's a workaround that correctly does what I originally intended:

goto BEGIN

:doit
    echo bar
    goto asdf
    :asdf
    echo baz
    goto :EOF

:BEGIN

echo foo
if 1 == 1 (
    call :doit
) else (
    echo quux
)

However, this doesn't answer my original question.

Answer 1

The target of a CALL or GOTO should never be inside a block statement within parentheses. It can be done, but as you see, the results are probably not going to be what you want.

The entire IF (...) ELSE (...) construct is parsed and loaded into memory before any of it is processed. In other-words, it is logically treated as one line of code. After it is parsed, CMD.EXE is expecting to resume parsing starting with the next line after the IF/ELSE construct.

After the parse phase, the complex command is executed from memory. The IF clause is processed properly and the ELSE clause is skipped properly. BUT within the IF (true) clause, you perform a GOTO :asdf, so CMD.EXE dutifly begins scanning for the label. It starts at the end of the IF/ELSE and scans to the bottom of the file, loops back to the top, and scans until it finds the label. The label happens to be within your IF clause, but the label scanner knows nothing about that detail. So when the complex command finishes executing from memory, batch processing resumes from the label instead of from the end of the complex IF/ELSE.

So at this point the batch processor sees and executes the next few lines

    echo baz
) else (
    echo quux
)

baz is echoed, and so is quux. But you might ask, "Why doesn't ) else ( and/or ) generate a syntax error since they are now unbalanced and no longer parsed as part of the larger IF statement?

That is because of how ) is handled.

If there is an open ( active when ) is encountered, then the ) is processed as you would expect.

But if the parser is expecting a command and finds a ) when there is not an active open (, then the ) is ignored and all characters on the remainder of the line are ignored! Effectively the ) is now functioning as a REM statement.