Date: Wed, 12 Aug 2020 22:38:28 +0300
On Wed, 12 Aug 2020 at 22:31, Bjarne Stroustrup <bjarne_at_[hidden]> wrote:
>
> I meant that as a general statement. Obviously, I prefer a simpler
> grammar, but simplifying the grammar should not be a sole of major
> reason for a change.
Right. The grammar is just a means to an end, and here's a C++ use case:
if you write nested loops, and want to just jump to the end of the
surrounding loop(*), now you don't
have to put that semicolon or an empty block statement there. While
that's just nice and convenient
on the surface level, it's also, in contrast, damn straight less
quirky than the status quo is.
I'm beginning to warm up to this. :)
(*) This has been proposed as a motivating use case for a labeled
break. We tell such proposal
authors "just use goto, if you can't bother refactoring your code into
separate functions". It's a forward-and-out-jumping
goto, so doesn't do mysterious scope/direction traversals that really
bad uses of goto do. The code ends up being
more straightforward than sprinkling more condition-nesting into it,
and when applied for reasonable lengths
of code, is quite readable.
>
> I meant that as a general statement. Obviously, I prefer a simpler
> grammar, but simplifying the grammar should not be a sole of major
> reason for a change.
Right. The grammar is just a means to an end, and here's a C++ use case:
if you write nested loops, and want to just jump to the end of the
surrounding loop(*), now you don't
have to put that semicolon or an empty block statement there. While
that's just nice and convenient
on the surface level, it's also, in contrast, damn straight less
quirky than the status quo is.
I'm beginning to warm up to this. :)
(*) This has been proposed as a motivating use case for a labeled
break. We tell such proposal
authors "just use goto, if you can't bother refactoring your code into
separate functions". It's a forward-and-out-jumping
goto, so doesn't do mysterious scope/direction traversals that really
bad uses of goto do. The code ends up being
more straightforward than sprinkling more condition-nesting into it,
and when applied for reasonable lengths
of code, is quite readable.
Received on 2020-08-12 14:42:03