On Fri, Aug 16, 2019 at 1:30 PM Tae Lim Kook via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> > Yeah, well, these ideas pop up every now and then. A paper containing
> > them, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf,
> > was discussed and rejected in Rapperswil 2014.
>
> Is there a reason that the proposal above was rejected?
> Perhaps a similar proposal with only the labelled break and
> continue would have a better chance of being accepted.
>

I once asked other committee members why the language doesn't automatically
define a type "super", which is always the first listed superclass in any
class which is a subclass of something else. Object Pascal, for example,
automatically defines such a thing, and it's handy. The response I got was
that, if you want that, you can easily in a single line write a typedef
that defines that type for you.

Likewise, I personally am a huge fan of "goto case" , because it provides a
means for telling the compiler that a fall-through to the next case is
intentional, as well as making certain types of switch statements much
clearer. But when I asked other committee members about it, they said
that, same reason: they don't like to add things to the language that are
already easily achievable in the language.

So for example, consider this routine:

double Pow_0_to_7(double base, int exponent) {
  double result = 1.0;
  double base2 = base * base;
  switch(exponent) {
    case 7:
      result *= base;
      goto case 6;
    case 6:
      result *= base2;
      goto case 4;
    case 5:
      result *= base;
      goto case 4;
    case 4:
      return result * base2 * base2;
    case 3:
      result *= base;
      goto case 2;
    case 2:
      return result * base2;
    case 1:
      return base;
    default:
      assert(exponent == 0);
      return 1.0;
  }
}

Without "goto case", it would be written like this:

double Pow_0_to_7(double base, int exponent) {
  double result = 1.0;
  double base2 = base * base;
  switch(exponent) {
    case 7:
      result *= base;
      goto case_6;
    case 6:
    case_6:
      result *= base2;
      goto case_4;
    case 5:
      result *= base;
      goto case_4;
    case 4:
    case_4:
      return result * base2 * base2;
    case 3:
      result *= base;
      goto case_2;
    case 2:
    case_2:
      return result * base2;
    case 1:
      return base;
    default:
      assert(exponent == 0);
      return 1.0;
  }
}

Which would not really be that bad.

I get the same feeling from your proposal and about N3879: the workarounds
aren't bad at all, so why make the language more complicated?