On Thu, Aug 5, 2021 at 3:26 PM Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
> It is a source of syntax ambiguity. Compare
> return;
> print("unreachable code")
>
> with
> return
> print("unreachable code")
Thank you for the explanation.
> Breaks followed that rule to keep open the possibility of labeled
> breaks. After goto, we gave up the idea of labeled breaks, but now I
> particularly would prefer that all of them (break/return/goto) followed
> this rule.
Without goto, any statements after transfer of control are
unreachable, and it is best for clarity not to have them. So the rule
makes perfect sense in this case.
With goto, well, they are reachable if there is a label statement just
after the transfer of control.
What speaks against relaxing the current restriction on the return
statement, so that it must be the last statement in its block, or it
must be immediately followed by a label statement?
Cheers,
V.
Think about it more practically. How WOULD you write code using goto that would put a label in that position? All of the ways that come to mind would be better served with other code structures.
Specifically, keep in mind that a goto that isn't the last statement of a block is necessarily an unconditional goto -- if it were conditional, it would be inside an if block. (If there's code after the goto in that if block, the goto is still unconditional from the perspective of that code.) So there are only two possibilities:
(1) An unconditional forward jump. This means you're skipping over code, unconditionally. That either means that code could be removed or commented out, or that there would be a label immediately following the goto statement for use by another goto. Sub-possibilities:
(1a) That other goto is earlier in the code. This is effectively implementing an if/else and could be replaced with that.
(1b) That other goto is later in the code. This is effectively implementing a special-case first iteration of a loop and could be replaced with a loop.
(2) An unconditional backward jump. This is just an uglier way of writing a loop and should be written as such.
Conditional gotos are way more useful -- the typical argument for supporting goto is to short-circuit out of a nested structure, and those are necessarily conditional.
/s/ Adam
