Re: Why is break not syntactically required to be the last statement in a block (anymore)?
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Why is break not syntactically required to be the last statement in a block (anymore)?
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: 2022年7月28日 20:59:34 +0200
On 28/07/2022 20:01, Egor Skriptunoff wrote:
On Thu, Jul 28, 2022 at 6:44 PM Lorenzo Donati wrote:
To avoid issues with what you mention, in order to just specify a
"static" level, also something like this:
break<4>
break ::4::
or
break @4
or whatever other syntax that is easily parseable with no excessive
lookahead and no ambiguities
"break 4" syntax is good enough:
the next statement cannot start with a literal number,
so only a simple look-ahead is required.
Would the "break 4" target be easy to locate when reading code?
Absolute location identifiers (such as "goto ::my_break_label::")
may be more understandable than relative values (such as "break 4").
In some cases, I agree that absolute locations are the clearer solution.
However, there are cases in which when you read an algorithm you don't
really care where are you jumping to, but that you jump out enough.
Of course you can litter your nested loops with something like
if some_condition then goto BAIL_OUT end
but this code can be completely understood only knowing where the
BAIL_OUT label is placed. It could be placed at the end of the nested
loops matrioska structure:
for ...
for ...
for...
end
end
end
::BAIL_OUT::
But you can't be sure until you check it. And this could be
annoying/error prone if that nested structure is several editor page
long (I assume you have a good reason to have such a deeply nested
structure spanning so much code, and that code cannot be refactored in a
more readable way avoiding the nesting and maintaining the same efficiency).
OTOH, the statement:
if some_condition then break 3 end
is immediately clear "locally".
Moreover, if the algorithm needs to bail out from only the, say, two
inner loops, but not the outer one, the syntax is easily understood.
With GOTOs you need additional labels, which may well become a
maintenance nightmare or source of errors.
With the "break N" syntax you have two source of errors: the break
statement and the nested loops structure. With "goto" you also add a
third element: the label position (and its name).
Of course I assume who reads the code already knows the structure of the
implemented algorithm and just needs to understand the details of the
implementation, otherwise "break 3" is as obscure as "goto BAIL_OUT".
BTW, it could be useful to have a special value for "bail out of ANY
loop", e.g. "break 0", regardless of nesting (it could be nice to be
able to write "break all", but this will introduce a new keyword, so meh!).
Anyway the "break N" feature has a clear advantage: it is a structured
alternative to "goto" with well understood jump target semantics.