On Fri, Aug 16, 2019 at 1:30 PM Tae Lim Kook via Std-Proposals <std-proposals@lists.isocpp.org> 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?