Case expressions and return patterns

[eernstg]

Dart 3.0 introduced patterns, including the following kind of construct known as an if-case statement:

if (json case [int x, int y]) {
  print('Was coordinate array $x,$y');
} else {
  throw FormatException('Invalid JSON.');
}

This statement has a semantics that makes it different from traditional if statements. In particular, it isn't specified as an if-statement whose condition is the expression json case [int x, int y]. The reason for this is that there is no expression of the form <expression> 'case' <guardedPattern>. Hence, an if-case statement does not have a condition expression of type bool, it has an expression (of an any type), and it has a pattern, and it chooses the "then" branch if and only if the pattern matches the value of that expression. Another specialty with if-case statements is that variable declarations in the pattern are in scope in that "then" branch.

This issue claims that we might as well turn the syntax <expression> 'case' <guardedPattern> into an expression in its own right. We're generalizing it a bit, and allowing it to occur in any place where we can have an expression. The new kind of expression is known as a <caseExpression>. For starters, it has static type bool, and it evaluates to true if and only if the match succeeds.

We say that the result type of the pattern is bool, which is true for all the patterns that we can write today.

This issue also proposes a new kind of pattern, <returnPattern>, which is used to specify a different value for the evaluation of the enclosing case expression when it matches, namely the matched value. In this case, the result type of the pattern is M? when the matched value type at the return pattern is M. The value of the pattern when the match fails is null.

Here are some examples illustrating the semantics (some less trivial examples can be seen in this comment):

void main() {
  // Case expressions of type `bool`.

  var b1 = 10 case > 0; // OK, sets `b1` to true.
  var b2 = 10 case int j when j < 0; // OK, sets `b2` to false.

  // Case expressions of other types.

  var s = "Hello, world!" case String(length: > 5) && return.substring(0, 5);
  var n = [1, 2.5] case [int(isEven: true) && return, _] || [_, double() && < 3.0 && return];

  Object? value = (null, 3);
  var i = value case (num? _, int j && return) when j.isOdd;

  // It works as follows.

  { // var b1 = 10 case > 0;
    bool b1;
    if (10 case > 0) {
      b1 = true;
    } else {
      b1 = false;
    }
    // `b1` has the value true.
  }

  { // var b2 = 10 case int j when j < 0;
    bool b2;
    if (10 case int j when j < 0) {
      b2 = true;
    } else {
      b2 = false;
    }
    // `b2` has the value false.
  }

  { // var s = "Hello, world!" case String(length: > 5) && return.substring(0, 5);
    String? s;
    if ("Hello, world!" case String(length: > 5) && String it) {
      s = it.substring(0, 5);
    } else {
      s = null;
    }
    // `s` has the value 'Hello'.
  }

  { // var n = [1, 2.5] case [int(isEven: true) && return, _] || [_, double() && < 3.0 && return];
    num? n;
    if ([1, 2.5]
        case [int(isEven: true) && final num result, _] ||
            [_, double() && < 3.0 && final num result]) {
      n = result;
    } else {
      n = null;
    }
    // `n` has the value 2.5.
  }

  {
    // Object? value = (null, 3); 
    // var i = value case (num? _, int j && return) when j.isOdd;

    Object? value = (null, 3);
    int? i;
    if (value case (int? _, int j) when j.isOdd) {
      i = j;
    } else {
      i = null;
    }
    // `i` has the value 3.
  }
}

Proposal

Syntax

<expression> ::= ... | <caseExpression>;
<caseExpression> ::= <conditionalExpression> 'case' <guardedPattern>
    ('=>' <expression>)?;

<expressionWithoutCascade> ::= ... | <caseExpressionWithoutCascade>;
<caseExpressionWithoutCascade> ::=
    <conditionalExpression> 'case' <guardedPatternWithoutCascade>;
<guardedPatternWithoutCascade> ::=
    <pattern> ('when' <expressionWithoutCascade>)?

<returnPattern> ::= <type>? 'return' <selector>*;

Static Analysis

With this feature, every pattern has a result type. The result type of every pattern which is expressible without this feature is bool.

The remaining patterns (which are only expressible when this feature is available) have a result type which is determined by the return patterns that occur in the pattern. They are specified below in terms of simpler patterns followed by composite ones.

The result type of a return pattern of the form return is the matched value type of the pattern. The result type of a return pattern of the form T return is T. The result type of a return pattern of the form return s1 .. sk where sj is derived from <selector> is the static type of an expression of the form v s1 .. sk, where v is a fresh variable whose type is the matched value type of the pattern. Finally, the result type of a return pattern of the form T return s1 .. sk is the static type of an expression of the form v s1 .. sk, where v is a fresh variable whose type is T.

For example, if the matched value type for a given return pattern P of the form return.substring(5).length is String then the result type of P is int. This is because v.substring(5).length has type int when v is assumed to have type String.

The result type of an object pattern that contains one field pattern with result type R, which is not bool, is R. It is a compile-time error if the object pattern has two or more field patterns with a result type that isn't bool.

It is a compile-time error if a listPattern, mapPattern, or recordPattern contains multiple elements (list elements, value patterns of the map, or pattern fields of the record) whose result type is different from bool. If all elements have result type bool then the result type of the pattern is bool. Otherwise, exactly one element has a result type T which is not bool, and the result type of the pattern is then T.

Consider a logicalAndPattern P of the form P1 && P2 .. && Pn where Pj has result type T which is not bool, and Pi has result type bool for all i != j. The result type of P is T. It is a compile-time error if a logicalAndPattern P of the form P1 && P2 .. && Pn has two or more operands Pi and Pj (where i != j) whose result type is not bool.

Consider a logicalOrPattern P of the form P1 || P2 .. || Pn where Pi has result type Ti, for i in 1 .. n. A compile-time error occurs if at least one operand Pj has result type bool, and at least one operand Pk has a result type T which is not bool. If all operands have result type bool then the result type of P is bool. Otherwise, the result type of P is the standard upper bound of the result types T1 .. Tn.

Consider a parenthesizedPattern P of the form (P1). The result type of P is the result type of P1.

Some other kinds of pattern also have the result type of their lone child: castPattern, nullCheckPattern, and nullAssertPattern.

The remaining patterns always have result type bool: constantPattern, variablePattern, and identifierPattern.

Assume that e is a case expression of the form e1 case P where P has result type T which is not bool; the static type of e is then T?. Assume that P has result type bool; the static type of e is then bool.

Assume that e is a case expression of the form e1 case P => e2. A compile-time error occurs if the result type of P is not bool. The static type of e is then T?, where T is the static type of e2.

With pre-feature patterns, it is an error if a pattern of the form P1 || .. || Pn declares different sets of variables in different operands Pi and Pj, with i and j in 1 .. n and i != j. This is no longer an error, but it is an error to access a variable from outside Pi or Pj unless it is declared by every operand P1 ... Pn, with the same type and finality.

The point is that we may well want to access different variables in return patterns: e case A(:final x, y: return.foo(x)) || B(:final a, b: return.bar.baz(a + 1)). For instance, a when clause which is shared among several patterns connected by || cannot use a variable like x, but the return pattern return.foo(x) can use it.

Variables which are declared by a pattern in a case expression are in the current scope of the pattern itself, and in the current scope of the guard expression, if any.

Moreover, such variables are in scope in the first branch of an if statement whose condition is a case expression (just like an if-case statement today), and in the first branch of a conditional expression (that is, (e case A(:final int b)) ? b : 42 is allowed). Finally, such variables are in scope in the body of a while statement whose condition is a case expression.

Dynamic Semantics

Evaluation of a case expression e case P where P has result type bool proceeds as follows: e is evaluated to an object o, and P is matched against o. If the match succeeds then the case expression evaluates to true, otherwise it evaluates to false.

Evaluation of a case expression e case P where P has result type T which is not bool proceeds as follows: e is evaluated to an object o, and P is matched against o, yielding an object r. If r is null then the case expression evaluates to null. Otherwise, r is a function, and the case expression then evaluates to r().

A return pattern of the form T return evaluates to () => v where v is a fresh variable whose value is the matched value when the matched value has type T, otherwise it evaluates to null. A return pattern of the form return evaluates to () => v where v is a fresh variable whose value is the matched value (and it never fails to match).

A return pattern of the form return s1 s2 .. sk where sj is derived from <selector> evaluates to the value () => v s1 s2 .. sk where v is a fresh variable bound to the matched value. A return pattern of the form T return s1 .. sk where sj is derived from <selector> evaluates to the value () => v s1 .. skwherevis a fresh variable bound to the matched value if the matched value has typeT. If the matched value does not have type T` then it evaluates to null.

For example, return.foo() evaluates to () => v.foo() where v is the matched value.

An object pattern that contains one field pattern with result type R, which is not bool, is evaluated by performing the type test specified by the object pattern on the matched value, yielding null if it fails, and otherwise evaluating each of the pattern fields in textual order. If every pattern field yields true, except one which yields a non-null object r then the object pattern evaluates to r. Otherwise the object pattern evaluates to null.

A listPattern, mapPattern, or recordPattern is evaluated in the corresponding manner, yielding the non-null object r from the element whose result type is not bool when all other elements yield true, and yielding null if any element yields false or null.

Consider a logicalAndPattern P of the form P1 && P2 .. && Pn where Pj has result type T which is not bool, and Pi has result type bool for all i != j. P is evaluated by evaluating P1, ..., Pn in that order. If every result is either true (when the result type is bool) or a non-null object r (when the result type is not bool), the evaluation of P yields r. Otherwise it yields null.

Consider a logicalOrPattern P of the form P1 || P2 .. || Pn where Pi has result type Ti, for i in 1 .. n. The case where Ti == bool for all i has the same semantics as today. Hence, we can assume that Ti != bool for every i. Evaluation of P proceeds by evaluating a subset of P1, ..., Pn, in that order. As long as the the result is null, continue. If this step uses all the operands P1 .. Pn then the evaluation of P yields null. Otherwise we evaluated some Pj to a non-null object r, in which case P evaluates to r.

Consider a parenthesizedPattern P of the form (P1). Evaluation of P consists in evaluating P1 to an object r, and P then yields r.

A castPattern P of the form P1 as T evaluates by evaluating P1 to an object r. If r has a run-time type which is T or a subtype thereof then P evaluates to r, otherwise P evaluates to null.

A nullCheckPattern P of the form P1? evaluates by evaluating P1 to an object r. If r is not null then P evaluates to r, otherwise P evaluates to null (that is, P evaluates to r in all cases).

A nullAssertPattern P of the form P1! evaluates by evaluating P1 to an object r. If r is not null then P evaluates to r, otherwise the evaluation of P completes by throwing an exception.

The remaining patterns always have result type bool (constantPattern, variablePattern, and identifierPattern), and they evaluate to true if the match succeeds, otherwise they evaluate to false.

Of course, an implementation may be able to lower patterns containing return patterns and get a behavior which isn't observably different from the semantics specified above without using any function objects, which is perfectly fine (even preferable because it is likely to be faster). However, it is important that the evaluation of a selector chain is only done in the case where the given return pattern "contributes to the successful match". If, in the end, the match fails, then we shouldn't have executed any of those selector chains. Similarly, if we have P1 || P2 and P1 fails but P2 succeeds then we must execute the selector chain for P2, at the very end, but it is not allowed to execute the selector chain for P1.

Versions

• Nov 1, 2024: Simplified return patterns (they cannot introduce variables any more). Inspired by @tatumizer, I generalized case expressions to support an optional => expression part, e.g., 41 case int() && final value => value + 1.
• Oct 30, 2024: First version which is reasonably complete.

[hydro63]

1. i'm for case as expression, since imo case should be expression since Dart 3, and shouldn't be left as it's own language construct.

2. i'm really iffy about the return pattern, or at least the specification as it stands. This is based on the example you've provided, where it took me considerable effort to understand what is actually being returned (without looking at the desugared code).

also, in the grammar for the case expression, is there any need for the with / without cascade division? From what i see, the grammar for both is the same, so unless i'm forgetting something, it could be a single rule, right? Could you please clarify why is not?

[leafpetersen]

I find some of the return patterns pretty hard to grok. In general, I think the examples here don't do a great job of motivating the feature, maybe there are some better ones that would be more convincing? For the examples above, I think there are better ways to write them in Dart as it exists now.

 // Case expressions of type `bool`.

//  var b1 = 10 case > 0; // OK, sets `b1` to true.
var b1 = 10 > 0;

//  var b2 = 10 case int j when j < 0; // OK, sets `b2` to false.
var b2 = 10 > 0;

  // Case expressions of other types.

//  var s = "Hello, world!" case String(length: > 5) && return.substring(0, 5);
var h = "Hello, world!"; // Might be nice to have let for this example
var s = (h.length > 5) ? h.substring(0, 5) : null

//  var n = [1, 2.5] case [int(isEven: true) && return, _] || [_, double() && < 3.0 && return];
  var n = switch ([1, 2.5]) {
          [int(isEven: true) && var i, _] => i,
          [_, double() && < 3.0 && var d] => d,
          _ => null
        };


  Object? value = (null, 3);
//  var i = value case (num? _, int return j) when j.isOdd;
var i = switch (value) { (num? _, int j) when j.isOdd => j, _ => null}

[hydro63]

@leafpetersen if we are talking purely about case being an expression / operator, then i'm actually for it. I'm sure that i'm not the only one that has wanted to use case in loops or tried to use case as a comparison operator. I have already thought about wanting to use case as a normal operator rather than as it's own construct.

if we are talking about the return pattern, i am against it purely because i can't read it. If there was more readable way to do it, i wouldn't mind.

[leafpetersen]

I'm sure that i'm not the only one that has wanted to use case in loops or tried to use case as a comparison operator.

Would you mind sharing some motivational examples? It's useful to see examples of how folks could imagine using a feature.

[hydro63]

@leafpetersen First of all, i want to admit, that when i was looking for examples for the case as expression / operator, it took me a long time to find an actual use-case, which made me lose confidence in this feature.

I remember wanting it, when i was writing parser combinator, but since it was only a hobby project, i didn't backup the code (*), and now i can't find it. There are other project where i wanted to use it (at least in some capacity), like recursive descent parser and DFA to regex transpiler, but i also didn't backup the projects.

But before you write off this feature, here are the use-cases i found:

1. boolean / filtering functions

final list = [...];
final filtered = list.where((e) => e case Foo(:int prop) || Bar(:int prop) when prop > 5);

// or
final filtered = list.where((e) {
  return e case Foo(:int prop) || Bar(:int prop) when prop > 5;
});

2. combining while(true) and if() break + possible destructuring inside the condition

// example 1 - when i was doing recursive descent parser
// nextTok -> Token?
while(nextTok case Token(type: .string || .number, :final value)){
  // can use value, and other fields we destructure 
  ...
}

// example 2
// parsePrimary() -> PrimaryNode?
while(parsePrimary() case var node?){
}

// without it - example 1
while(true){
  if(nextTok == null || ![TokenType.string, TokenType.number].contains(nextTok.type)) break;
  final value = nextTok.value;
}

// without it - example 2
while(true){
  final node = parsePrimary();
  if(node == null) break;
}

In essence, after thinking about it, i think the use-cases for both are niche, but are also quite good and don't cause many problems. In the first case, the destructured variables would be scoped to the case expression, and in the while case, they would be passed to the block.

These are all the uses i found, so you can decide if you wish to have it, or not. Either way, i won't complain whether it's implemented or not.

*i hate overusing git for short projects

[leafpetersen]

@hydro63 thanks!

I think the while example is compelling, and indeed there is already an issue tracking this from when we shipped the original feature.

The boolean case has also been raised elsewhere.

I'd suggest giving those issues a thumbs up since I think they will likely remain the canonical issues for those specific sub-features.

@eernstg:

Are going to support this, too?

var x = a > b && return a || return b;

[hydro63]

Are going to support this, too?

@tatumizer i suppose not. Disregarding the missing case keyword, patterns currently don't allow comparing with non constant expression, meaning it would be a compile error.

Edit - i thought the comment was referencing this issue, but it was instead referencing another proposal.

[eernstg]

Here are some examples where case expressions are useful, based on the document Dart Patterns -- Survival of the fittest:

// Currently in Flutter code.

String? runtimeBuildForSelectedXcode;
final Object? iosDetails = decodeResult[iosKey];
if (iosDetails != null && iosDetails is Map<String, Object?>) {
  final Object? preferredBuild = iosDetails['preferredBuild'];
  if (preferredBuild is String) {
    runtimeBuildForSelectedXcode = preferredBuild;
  }
}

// Using current patterns.

final String? runtimeBuildForSelectedXcode = switch (decodeResult[iosKey]) {
  {'preferredBuild': final String preferredBuild} => preferredBuild,
  _ => null,
};

// Using a case expression.

final String? runtimeBuildForSelectedXcode =
    decodeResult[iosKey] case {'preferredBuild': String return};

The main abbreviation above comes from the fact that a case expression that contains a return pattern evaluates to null when the match fails. However, that does seem to be a useful behavior to get implicitly.

Note that this semantics is similar to the semantics of expressions like a?.b?.c: The expression as a whole evaluates to null if "anything went wrong" during the evaluation, and the enclosing code can detect this and act accordingly.

It could be argued (for expressions using null shorting like a?.b?.c as well as for case expressions) that we can also get null in other ways (e.g., a is non-null, a.b is non-null, but a.b.c is null). We must take care to avoid interpreting the result null to mean "the situation I required doesn't exist" if it really means "the situation does exist, but we successfully looked up null". However, this doesn't seem to create huge issues today (e.g., with null shorting), and it should also be OK to have to handle it with case expressions. After all, the exact same issue comes up with a switch expression that includes a default case of the form _ => null.

// Currently in Flutter code.

T? get currentState {
  final Element? element = _currentElement;
  if (element is StatefulElement) {
    final StatefulElement statefulElement = element;
    final State state = statefulElement.state;
    if (state is T) {
      return state;
    }
  }
  return null;
}

// We could already simplify this using pre-existing Dart features.

T? get currentState {
  final Element? element = _currentElement;
  if (element is StatefulElement) {
    final State state = element.state;
    if (state is T) return state;
  }
  return null;
}

// Using current patterns.

T? get currentState => switch (_currentElement) {
  StatefulElement(:final T state) => state,
  _ => null,
};

// Using a case expression.

T? get currentState => _currentElement case StatefulElement(state: T return);

The most interesting part above is probably the type tests: The case expression evaluates to null if _currentElement isn't a StatefulElement, or if it is a StatefulElement whose state doesn't have the type T (which is a type variable of an enclosing class). In other words, we're describing a situation that includes several assumed types, and we're using (_currentElement as StatefulElement).state if everything is OK. If anything isn't OK then we just return null. We can say this concisely because "anything isn't OK" is an implicit property of several parts of this expression.

// Currently in Flutter code.

class ParsedProjectGroup {
  ParsedProjectGroup._(this.identifier, this.children, this.name);

  factory ParsedProjectGroup.fromJson(String key, Map<String, Object?> data) {
    String? name;
    if (data['name'] is String) {
      name = data['name']! as String;
    } else if (data['path'] is String) {
      name = data['path']! as String;
    }

    final List<String> parsedChildren = <String>[];
    if (data['children'] is List<Object?>) {
      for (final Object? item in data['children']! as List<Object?>) {
        if (item is String) {
          parsedChildren.add(item);
        }
      }
      return ParsedProjectGroup._(key, parsedChildren, name);
    }
    return ParsedProjectGroup._(key, null, name);
  }

  final String identifier;
  final List<String>? children;
  final String? name;
}

// Using current patterns.

class ParsedProjectGroup {
  ParsedProjectGroup.fromJson(this.identifier, Map<String, Object?> data)
      : children = switch (data['children']) {
          final List<Object?> children => children.whereType<String>().toList(),
          _ => null,
        },
        name = switch (data) {
          {'name': final String name} => name,
          {'path': final String path} => path,
          _ => null,
        };

  final String identifier;
  final List<String>? children;
  final String? name;
}

// Using a case expression.

class ParsedProjectGroup {
  ParsedProjectGroup.fromJson(this.identifier, Map<String, Object?> data)
      : children = data['children'] case List return.whereType<String>().toList(),
        name = data case {'name': String return} || {'path': String return};

  final String identifier;
  final List<String>? children;
  final String? name;
}

In the example above it's worth noting that e case T return works like the safe cast operation which is requested in #399, that is e as? T. Another reason why the expression is concise is that we can use return in two different OR-branches of the second case expression, using the value of the key 'name' in one case and 'path' in the other case.

// Currently in Flutter code.

int? findIndexByKey(Key key) {
  if (findChildIndexCallback == null) {
    return null;
  }
  final Key childKey;
  if (key is _SaltedValueKey) {
    childKey = key.value;
  } else {
    childKey = key;
  }
  return findChildIndexCallback!(childKey);
}

// Using current patterns.

int? findIndexByKey(Key key) {
  late final Key childKey = switch (key) {
    _SaltedValueKey(:final Key value) => value,
    final Key key => key,
  };

  return findChildIndexCallback?.call(childKey);
}

// Using a case expression.

int? findIndexByKey(Key key) => findChildIndexCallback?.call(
  key case _SaltedValueKey(value: Key return) || return
);

In the example above we again get rid of some repetition of names. Note that we still avoid evaluating the key when findChildIndexCallback is null.

// Currently in Flutter code.

Diagnosticable? _exceptionToDiagnosticable() {
  final Object exception = this.exception;
  if (exception is FlutterError) {
    return exception;
  }
  if (exception is AssertionError && exception.message is FlutterError) {
    return exception.message! as FlutterError;
  }
  return null;
}

// Using current patterns.

Diagnosticable? _exceptionToDiagnosticable() => switch (exception) {
  AssertionError(message: final FlutterError error) => error,
  final FlutterError error => error,
  _ => null,
};

// Using a case expression.

Diagnosticable? _exceptionToDiagnosticable() => exception case
  AssertionError(message: FlutterError return) || FlutterError return;

This example once again uses a case expression to obtain a value with a choice: If we're looking at an AssertionError whose message is a FlutterError then we will use that message, if we're looking at a FlutterError we'll use that, and everything else will be ignored (that is, replaced by null).

// Currently in Flutter code.

final bool hasError = decoration.errorText != null;
final bool isFocused = Focus.of(context).hasFocus;

InputBorder? resolveInputBorder() {
  if (hasError) {
    if (isFocused) {
      return decoration.focusedErrorBorder;
    }
    return decoration.errorBorder;
  }
  if (isFocused) {
    return decoration.focusedBorder;
  }
  if (decoration.enabled) {
    return decoration.enabledBorder;
  }
  return decoration.border;
}

// Using current patterns.

final bool isFocused = Focus.of(context).hasFocus;

InputBorder? resolveInputBorder() => switch (decoration) {
  InputDecoration(errorText: _?) when isFocused => decoration.focusedErrorBorder,
  InputDecoration(errorText: _?)                => decoration.errorBorder,
  InputDecoration() when isFocused              => decoration.focusedBorder,
  InputDecoration(enabled: true)                => decoration.enabledBorder,
  InputDecoration()                             => decoration.border,
};

// Alternative solution using current patterns.

InputBorder? resolveInputBorder() => switch ((
  enabled: decoration.enabled,
  focused: Focus.of(context).hasFocus,
  error: decoration.errorText != null,
)) {
  (enabled: _,     focused: true, error: true) => decoration.focusedErrorBorder,
  (enabled: _,     focused: _,    error: true) => decoration.errorBorder,
  (enabled: _,     focused: true, error: _)    => decoration.focusedBorder,
  (enabled: true,  focused: _,    error: _)    => decoration.enabledBorder,
  (enabled: false, focused: _,    error: _)    => decoration.border,
};

// Using a case expression (and assuming #4124).

final bool isFocused = Focus.of(context).hasFocus;

InputBorder? resolveInputBorder() => isFocused
    ? decoration case _(errorText: _?) && return.focusedErrorBorder ||
          return.focusedBorder
    : decoration case _(enabled: true) && return.enabledBorder ||
          return.border;

In this last example we're inspecting the given decoration when focused, "returning" its focusedErrorBorder if it has an errorText, otherwise its focusedBorder; and similarly for the two cases where it isn't focused.

[eernstg]

@hydro63 wrote:

is there any need for the with / without cascade division?

It allows a case expression to occur in a location where an <expressionWithoutCascade> is required. The main case would be in cascades:

void main {
  var x = MyClass()
    ..property1 = e1 case P1
    ..property2 = e2 case P2;
}

It's probably a good trade-off to accept the slightly more complex grammar in return for being able to use case expressions in places like this. Otherwise we would just have to put () around the case expression, but that may seem inconvenient, especially if viewed by someone who knows that this requirement could easily have been avoided. ;-)

I'm sure that i'm not the only one that has wanted to use case in loops

The special exception about case expressions in if statements is that the variables they declare are in scope in the body.

However, it should certainly be possible to allow a while loop to have a case expression as its condition, with the same special treatment of the scope, and similarly for a few other constructs (probably not do-while because it would be really weird to have declarations at the end of a block where they are in scope).

In all other locations we can use a case expression as an expression, but the variables that it declares are not in scope anywhere other than in the when clause of the case expression itself, if any.

@leafpetersen wrote:

I think the examples here don't do a great job of motivating the feature

Indeed, the examples in the original posting were only intended to illustrate the semantics. A set of more meaningful examples can be found here.

@tatumizer wrote:

Are going to support this, too?

var x = a > b && return a || return b;

I don't quite know how this would generalize, but var x = a > b ? a : b; seems to do the job for this example.

However, we can use a case expression to avoid declaring some variables (and writing those names twice):

abstract class A { int get a; }
abstract class B { double get b; }

void foo(Object o) {
  // Using a case expression.
  var x = o case A(a: return) || B(b: return); // `x` has type `num?`.
  
  // Using a switch expression.
  var y = switch (o) {
    A(:final a) => a,
    B(:final b) => b,
    _ => null,
  };
}

We can also use it to perform a bit of processing on the objects that we've found via pattern matching:

abstract class A { double get a; }
abstract class B { String get b; }

void foo(Object o) {
  var x = (o case A(a: return.toInt()) || B(b: return.length)) ?? 42; // `ab` has type `int`.
}

@eernstg:
The use of return in expressions has been a subject of debate.
Some commenters suggested that the syntax of conditional expression cond ? a : b can be expanded by adding support for return (after all, we allow throw, which makes return a legitimate option).
However, the suggested meaning of return in var x = a > b ? return a : b was different: it was supposed to signify the return from the containing function.

The question closely related to this: consider

void foo(Object o) {
  var x = o case A(a: return) || B(b: return);
  // VS 
  o case A(a: return) || B(b: return);    
}

Is the second expression allowed?
If not, on what grounds?

[eernstg]

The use of return in expressions has been a subject of debate.

Right, that's probably #2025. That would be a separate proposal, and it wouldn't conflict with this one (in this proposal return is parsed as a pattern, but in #2025 it is parsed as an expression).

The different forms of return pattern do not give rise to a returning completion of the current expression evaluation or statement execution, they just specify the value of the current pattern during a pattern matching process.

void foo() {
  var x = 1 case return;
  print('Still here!'); // Yes, this will be printed, and `x` has the value 1.
}

.. the suggested meaning of return in var x = a > b ? return a : b was different: it was supposed to signify the return from the containing function.

Exactly. And the parser will have no difficulties knowing that return a is an expression in this case.

void foo(Object o) {
  var x = o case A(a: return) || B(b: return); // OK.
  // VS 
  o case A(a: return) || B(b: return); // OK.
}

Both case expressions will investigate the object o; if it's an A then the case expression evaluates to (o as A).a; if it's a B then the case expression evaluates to (o as B).b; otherwise it evaluates to null.

In line 1 of the body of foo, this result is stored in x. In line 3 it is discarded. That's OK, even though it wouldn't be very useful in this case. If you just want to have the side effects of calling a respectively b then you could do o case A(a: _) || B(b: _);.

That would be a separate proposal, and it wouldn't conflict with this one (in this proposal return is parsed as a pattern, but in #2025 it is parsed as an expression).

The compiler can certainly parse the same word differently in different contexts, but the problem is that the user has to parse it in the head, which may lead to confusion. There's nothing magical in the case keyword that would suggest a different interpretation of the subsequent "return". Or you think there is?

---

Unrelated: I think you are overdoing it in B(b: return.length). Is there a precedent for this? Could you also write B(b: return +1)? Or the syntax is reserved for chains only? Why not require the explicit value in return, like:
B(b: return b.length)