[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: 4.4 break and return: just before elseif?
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Fri, 6 Aug 2021 13:45:01 +0200
On 05/08/2021 18:59, Coda Highland wrote:
On Thu, Aug 5, 2021 at 9:56 AM Viacheslav Usov <firstname.lastname@example.org> wrote:
On Thu, Aug 5, 2021 at 3:26 PM Roberto Ierusalimschy
It is a source of syntax ambiguity. Compare
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
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?
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.
IIRC one of the reasons GOTOs where introduced was to support automatic
code generators (especially for finite state machines).
In that case the option of using other code structures could not be
practical, since the code generator would have to be more complex and
generate loops using explicit loop structures instead of gotos.
Therefore adding restrictions on label placements could be detrimental
to simpler code generators.
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.