Switch expressions with some cases that need a body

[TimWhiting]

Switch expressions are really useful, however, In the past few days of working with them frequently I've run into the problem where most of my bodies of the cases are expressions, but I need a proper body for the minority of them. In such cases I have to revert everything to a switch statement (it's good that there is an assist for it), or I have to create an immediately invoked function. This is poor user experience.

return switch (this) {
      Ref() => k(this),
      // ... etc
      Lambda(:final formals, :final body) => (){
         //... Some code
         return x;
      }(),
    };

My proposal would be to allow a body instead of an expression in switch expressions. The body has the caveat that it cannot use a break / continue, and has to have a return statement. So the previous example would change to this: The semicolon of the return statement then separates the cases.

return switch (this) {
      Ref() => k(this),
      // ... etc
      Lambda(:final formals, :final body):
         //... Some code
         return x;
    };

[rrousselGit]

The fact that were using => makes me really wish that we could write:

final a = switch (obj) {
  pattern {
    return 42;
  } 
}

(with or without a ":" after the pattern)

I often switch back and forth between => and {return} depending on what's most readable for the given situation.

[TimWhiting]

That would be most consistent with function body / function expression bodies, which is actually probably more consistent for the feature than using switch statement body syntax.

I don't know which would fit into the grammar better.

[eernstg]

We have had some proposals about a construct which is often called 'block expressions'. Cf. #2848 (comment).

They could do the job, and they amount to the same syntax except for the parentheses:

  return switch (this) {
    Ref() => k(this),
    // ... etc
    Lambda(:final formals, :final body) => {
        //... Some code
        return x;
      },
  };

The block expression is quite similar to the function literal application () { /*my code here*/ } (), but there is no function object at run time, which means that there is no run-time cost as there would be with the function literal.

[TimWhiting]

Yes, I do think that this featured could be more general as in your linked issue.

However, since that feature will not be available for awhile most likely, I think it would be good to support for a refactoring assist to convert an expression to an immediately invoked function expression.

[munificent]

I agree this is an annoying wart of the syntax.

If I had a time machine, Dart would have always been an expression-based language. But I don't, and it isn't, so I tried to fit patterns and switch expressions in as gracefully as I could given that Dart already does make a distinction between expressions and statements.

Something like block-expressions could help, though it makes me wonder if we should consider just trying to actually do the whole thing and make the language expression-oriented.

[TimWhiting]

If you look at the changes recently, they are heavily expression oriented:

Collection elements
Records
Patterns

The first two work in a statement oriented language, because collection elements are only useful in expression position, records are part of patterns to a large degree, but as just a datastructure they are mostly a anonymous constructor expression. Patterns as you mentioned is really hard to put into a statement oriented language. I think it is great that it is finally here. I wouldn't go back to pre dart 3.0, but the experience has yet to feel polished in my opinion. This can and I believe will come over time, however I wonder if there will need to be some larger breaking changes as far as syntax goes to make it actually feel polished.

Something like block-expressions could help, though it makes me wonder if we should consider just trying to actually do the whole thing and make the language expression-oriented.

I'm curious what you envision for this? Is a larger breaking change with an automated syntax migration needed in your opinion to make dart an expression first language?

[rrousselGit]

They could do the job, and they amount to the same syntax except for the parentheses:

  return switch (this) {
    Ref() => k(this),
    // ... etc
    Lambda(:final formals, :final body) => {
        //... Some code
        return x;
      },
  };

My two cents on this is that it looks a bit weird.

=> {} is reminiscent of JS. It's not something we see in Dart.

It'd be quite confusing imo

[braj065]

Like any other Dart function syntax is expressed this can folllow the same. the user should be able to write either of below
Lambda(:final formals, :final body) {
//... Some code
return x;
},
OR
Lambda(:final formals, :final body) => x,

[munificent]

Lambda(:final formals, :final body) {
//... Some code
return x;
},
OR
Lambda(:final formals, :final body) => x,

Yes, I think that would work, though we have to be careful that it doesn't run into an ambiguity around map patterns or get in the way of other pattern syntax we might want to add.

The harder question is what the semantics of that block body are. I don't think return in the middle of a block should mean "yield this value from the block". Users expect return to return from functions and I think that's a good property to maintain.

I would be tempted to do something Rust-like and say that a block yields the value of the last statement in it (which would be void if the last statement wasn't an expression statement or some other statement that yields a value like a nested block).

But making the language expression oriented like this would be a big change, and I have no idea if there is a coherent design that would hold together and, if so, if we could actually ship it and migrate the world onto it without too much chaos.

[dgreensp]

I humbly propose the do-give expression:

var x = do {
  // ...
  give y;
};

The give keyword would immediately break out of the innermost do expression. give would only be considered a keyword when syntactically within a do-expression (for backwards compatibility).

In the switch example:

  return switch (this) {
    Ref() => k(this),
    // ... etc
    Lambda(:final formals, :final body) => do {
      //... Some code
      give x;
    },
  };

[mateusfccp]

I humbly propose the do-give expression:

var x = do {
  // ...
  give y;
};

The give keyword would immediately break out of the innermost do expression. give would only be considered a keyword when syntactically within a do-expression (for backwards compatibility).

In the switch example:

  return switch (this) {
    Ref() => k(this),
    // ... etc
    Lambda(:final formals, :final body) => do {
      //... Some code
      give x;
    },
  };

To reuse syntax, we could use yield instead.

[dgreensp]

To reuse syntax, we could use yield instead.

I guess the first question is, can you return or yield from a do-expression? It certainly could be allowed; the semantics are easy to imagine. Some languages (like Kotlin) even make return itself an expression, making it normal to return from the middle of an expression.

If return and yield are not allowed (with their usual semantics) inside a do-expression, the question becomes whether it is confusing to see one of those keywords used for exiting a do-expression. It was already commented that using return is not desirable, and the same objection could apply to yield.

[mateusfccp]

I would say we shouldn't allow yield inside of a do block. IMO do blocks should be only to "build" a complex expression, and shouldn't have side-effects. Although we can't control, for instance, if a function called inside a do block causes side-effects (I'm actually fond of languages that are explicit about side-effects, but this would be a major change in Dart's paradigm), we could have some controls regarding it, for instance:

• disallow yield and return (disregarding the question about whether it
  would be confusing to repurpose the keywords)
• disallow calling void functions
• disallow discarding values (i.e. if one calls a function, the returned value must be used)

I can see how these restrictions may cause other problems. For instance, if one want to build a list inside the do block, they are forced to use a collection-for instead of a for+list.add.

Between return and yield, I think the later is semantically more appropriate, and less confusing, but one can, indeed, argue that this may be confusing inside sync* functions.