Can switch expressions be used in const contexts?

[srawlins]

The introduction to switch expressions briefly compares them to conditional expressions, which are allowed in const contexts. Are switch expressions?

E.g. this is legal and I imagine useful.

const a = 1;
const b = 2;
const c = a == b ? 3 : 4;

[eernstg]

The treatment of a conditional expression in connection with constant / potentially constant expressions does allow for abstractions that we can't express otherwise (which could be taken to mean that it is useful):

class C {
  final int i;
  const C(int j, bool b) : i = b ? j : j + 1;
}

I don't think we're in a hurry to decide on switch expressions vs. constant expressions, because constant switch expressions could always be added as a later enhancement of the language.

However, you could say that they are covered semantically already, to the extent that we can express all the matching tests as constant expressions:

class C {
  final String s;

  // Emulate this:
  // const C(int i) : s = switch (i) {
  //   case 0 => '0',
  //.  case 1 => '1',
  //.  default => 'many',
  // };
  //
  const C(int i) : s = i == 0 ? '0' : (i == 1 ? '1' : 'many');
}

In any case, we would very quickly reach a point where it is desirable to allow things like myParameter == MyEnum.someValue (and that is currently not a constant expression), so it's probably OK to deal with this whole topic separately, and just say that switch expressions aren't constant for now.

[munificent]

I agree with Erik. In principle, yes, I'd like to support them. I'd like to support as much in constants as we reasonably can. In practice, if we find ourselves pressed for time, I'd be fine with punting on it to a future release.

[lrhn]

We currently don't allow any kind of destructuring in constant expressions. We don't allow constantList[0], even though knowing the constant list at compile time would make it very easy to actually implement it. (The String.length is the only exception, but it shows that we can and do have exceptions.)

If we allow switch expressions in potentially constant expressions, we open the door to general patterns, which can destructure general objects. So, we'd have to restrict the patterns you can use in constant switches to the point where it might not feel like a real switch any more, and users will have to remember all those exceptions.

I'd like to allow constantRecord.$0 as a constant expression (or even potentiallyConstantRecord.$0 as a potentially constant expression). That's a very localized affordance.

Because of this, I'd want to postpone constant switches. There are so many things that would be nice to do in constant expressions, but I'd rather do a complete overhaul at some later point, than add individual features in a piecemeal way. I fear doing the latter might lock us into some choices that would make the better overhaul too hard to succeed, and the pieces will have to be so restricted, because of the other restrictions we still have, that they become hard to use (unless you remember all the precise restrictions on how to use an otherwise general language construct).

[munificent]

The point about having to carefully restrict which kinds of patterns are allowed is a good one.

Because of this, I'd want to postpone constant switches.

SGTM. I'll move this into the "later" label and let's plan that the initial release of patterns does not allow switch expressions as const expressions.

[eernstg]

Do we need to introduce the notion of 'constant patterns', and use them for things like "const P = e; is a compile-time error unless P is a constant pattern"?

[munificent]

Do we need to introduce the notion of 'constant patterns', and use them for things like "const P = e; is a compile-time error unless P is a constant pattern"?

Yes, probably. (Though I would call them "pattern constants" to distinguish them from the existing "constant patterns" like case const Foo():.)