On Mon, Nov 6, 2023 at 9:58 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I reply in series below to Ville, Giuseppe, Jonathan, Marcin and Brian
>
>
> Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
> >
> > Yeah well, perhaps the solution to that problem isn't a facility
> > spelled "not continue". Because for
> > !continue, that's a valid alternative spelling.
>
>
> I've no idea what you mean here. "!continue" is presently a compiler
> error with g++:
>
> <source>: In function 'int main()':
> <source>:10:36: error: expected primary-expression before 'continue'
> 10 | for ( int i = 0; i < 5; ++i ) !continue;
> | ^~~~~~~~
> Compiler returned: 1
>
>
> Giuseppe D'Angelo wrote:
> >
> > In Perl this is called `redo`, which is a much much much better name
> > than `!continue`.
>
>
> Yeah fair enough we could have "__redo" or "_Redo" instead of
> "!continue". Personally I like "!continue" but the exact syntax isn't
> important right now.
>
>
> Jonathan Wakely wrote:
> >
> > Yeah, obviously it means "don't continue" i.e. stop looping. But we have break for that.
>
>
> I'm trying to learn German at the moment, and I still pause for a
> second before saying "You must not do that", because I don't want to
> mistakenly say "You don't need to do that". First I remind myself that
> "Du musst das nicht machen" imposes no restrictions, and so then by
> deductive reasoning I know that I've to pick out a different verb to
> say "You must not".
>
> Similarly with C++, if everyone knows that 'break' breaks out of a
> loop, then everybody's gonna know that "!continue" must do something
> else. Nobody who's been programming in C++ for more than a week is
> going to think that "!continue" breaks out of a loop.
>
> Here's another few possible syntaxes:
> --continue;
> continue(skip);
>
>
> Marcin Jaczewski wrote:
> >
> > There is idiom like this with `erase`:
> >
> > ```
> > if (condition)
> > {
> > p = v.erase(p);
> > }
> > else
> > {
> > ++p;
> > }
> > ```
> >
> > but do not know if this is good code practice as it is very easy to
> > make mistakes.
>
>
> This is exactly what I'm getting at here -- having a simple language
> feature that allows us to write simple code. When we have to do
> gymnastics -- and yes I'll admit it's fun sometimes especially when
> programming microcontrollers -- those gymnastics can have bugs in
> them, and just make the code more complex.

"Simple language feature that allows us to write simple code" applies
only to code that is common enough to *need* to be simplified. "I
wrote this thing once and maybe it could be made simpler with a
language feature" isn't a good enough justification for that language
feature.

Language features have costs. Not just in terms of getting them
standardized, but learning what they do. Rarely used language features
are highly costly. Because it's rarely used, many programmers have
never seen it before and don't know what it means.

If you see "!continue" or any other spelling you care to propose, and
you've never seen it before, you would have no clue what it means.

That's bad.

A thousand tiny language features that deal with tiny edge cases that
most users never encounter is not how you design a language.