Discussion: block expressions

[alrz]

block expressions

A block expression lets you to use statements in an expression context, but restricted to assignments, initializers and the switch expression for easier disambiguation.

var x = {
  foreach (var item in list) {
    if (item == value) {
      break true;
    }
  }
  break false;
};


var y = e switch {
  true => {
    using (r) {
      break o.M();
    }
  },
  _ => null
};

->

bool x;
foreach (var item in list) {
  if (item == value) {
    x = true;
    goto _lable;
  }
}
x = false;
_label:

object y;
if (e == true) {
  using (e) {
    y = o.M();
  }
} else {
  y = null;
}

To return the result from a block expression we use break <expression> syntax. Yet break; and return; statements are permitted and would work the same way they do today. A block expression need a break <expression>; to be always reachable - just like return in non-void returning methods.

Open question: where else we could permit a usage of block expressions? This is the argument against more expression-based constructs like lock and using expressions, so that we can use the same statement form in an expression context.

var x = {
  lock (o) {
    // ..
    break e;
  }
};

PS: I suggested this as an alternative under sequence expressions but I figured they are actually very different features and make sense beside each other. (I suspected this is a dup but couldn't find any)

[gulshan]

I think allowing immediate execution of local function and labmdas will serve the same purpose. Some previous discussions can be found in #249 and #960

[orthoxerox]

This is an interesting proposal.

On one hand, block expressions are more flexible than sequence expressions, because you are not restricted to a single exit point. They also look much nicer in a multiline context.

On the other hand, they are much harder to comprehend with multiple exit points.

I would probably allow them in all contexts, except method/lambda expression bodies and expression statements.

[alrz]

There is a couple of issues with allowing this in other places:

Verbosity: sometime you just want to capture some value in the middle of an expression,

if ((var x = expr; M(x.a, x.b)))

// instead of 

var x = expr;
if (M(x.a, x.b))
// or
if (expr is var x && M(x.a, x.b))

Rewriting this with a block expression is more verbose than current workarounds, and sometime confusing.

if ({ var x = expr; break M(x.a, x.b); })

Ambiguity: There are places that this will cause an extensive look ahead, such as:

// array initializers
int[] x =
{ // we don't know if this is a block expression until we reach a statement

// block statements
{ // we don't know if this is a block expression until we reach a `break <expression>`

With a limited context, we no longer need to deal with such ambiguities.

That being said, I don't think this can be considered as an "alternative" to sequence expressions, but enables scenarios that cannot be expressed in a self-contained way.

[qrli]

var x = {
  foreach (var item in list) {
    if (item == value) {
      break true;
    }
  }
  break false;
};

The first break is already ambiguous, to human. Break the foreach loop or the block?

[alrz]

Break the foreach loop or the block?

@qrli both? it has the same effect as return in loops in other places. If you want to break out of loop you need to use the break; statement.

[qrli]

@alrz I realized that after pondering for a moment. Just wanted to say it is confusing, as break is to break the nearest loop and your break expr behave differently.

[alrz]

The break statement means get out of the current switch/loop. Now, when it's followed by an expression, it means get out of the current block expression with this value. I think it perfectly fit to the current control flow. See, you can simulate a switch expression with it:

x = {
  switch(e) {
    case 0: break true;
    case 1: break false;
    default: break (bool?)null;
  }
};

[theunrepentantgeek]

Having the destination of break change radically just because it has an express afterwards would be really confusing.

I think this needs a different keyword - the existing behaviour of return is much closer, but perhaps not a good choice.

[jnm2]

This would prevent the possibility of labeled break.

[rummelsworth]

I like the idea of block expressions. It's a useful feature in some other languages. Anonymous methods and local functions don't cover all the scenarios in which block expressions would be useful.

It seems essential to pick a different keyword for the result of the block expression, because otherwise some useful scenarios disappear. Perhaps use, for example:

void Foo()
{
    while (true)
    {
        // ... other logic ...
        
        char c = Read() ?? // hypothetical Read that returns nullable char
        {
            if (someCondition)
            {
                return; // exits Foo, avoids Bar()
            }

            if (anotherCondition)
            {
                break; // exits the while loop, allows Bar()
            }

            use '#'; // new contextual keyword for resolving a block expression with a result
        };
        
        // ... other logic ...
    }
    
    Bar();
}

As far as suggestions to just use anonymous methods and local functions: If you try to put the contents of that block expression in anything that pushes a new frame, the return won't do what you want and the 'break' won't compile.

[gulshan]

I think the restriction that local functions don't know about where it's being called and thus not being able to break from outer loops or return from outer function, is a good thing. Keeps the code simple. If outer break/return is necessary, maybe it's better to not use a block/local anonymous function.

[alrz]

https://github.com/tc39/proposal-do-expressions

[NottocD]

I find myself wishing for a switch expression more often than I find myself wishing for block expression. However, in the case of a switch expression, I believe a unique syntax (just as there's a unique syntax for the ternary conditional operator) would add clarity. As an example, using a type of BNF:

::= : | * :
::= | @
::= ?>

Where evaluates to a single value that matches a or selects the default key: *
Rules:

1. all must result in the same type
2. if * case is not defined then default(type) is returned for an unmatched
3. the switch expression has the same order of operations as the ternary conditional operator.

[HaloFour]

@NottocD

I find myself wishing for a switch expression more often than I find myself wishing for block expression.

Switch expressions are coming to C# 8.0.

However, in the case of a switch expression, I believe a unique syntax (just as there's a unique syntax for the ternary conditional operator) would add clarity.

I disagree. The ternary operator is fairly confusing, to the point where it's often not recommended for anything but the most simple expressions. A switch expression will certainly be more complicated thus a more structured syntax would provide more clarity, especially to anyone who has to read that code after it has been written.

if * case is not defined then default(type) is returned for an unmatched

It will result in a runtime exception. Anything else, especially a default value, would only be a very subtle vector for bugs.

[gregsn]

Restricting the usage as stated in the first sentence of the proposal feels weird to me. A block expression should be allowed in all places where an expression is expected.

my take on it:
return should be the keyword to return a result.

int foo()
{
  var x = { return 0; }
  beep();
}

beeps.

int foo()
{
  return 0;
  beep();
}

doesn't.

IntelliSense tells me which code block is affected by the return statement as known from keywords like break and continue.

var ok = foo() && (bar() || { beep(); return item.MyExpensiveMethod(); }
only beeps if foo() and not bar().

In essence, a block expression can always be translated to a local function declared in a particular scope. We just drop the declaration and invocation syntax. In other words, semantically it's the invocation of an anonymous local function.

I think users often like to understand ideas once and then apply them in unforeseen scenarios. If we could state that a block expression isn't much more than the invocation of an anonymous local method then it's not far fetched to assume from a users perspective the following to work as well:
a C# style sequence expression: var seq = { foreach (var x in xs) if (foo(x)) yield return x; } by extending the idea to co-methods.

Sugaring the sequence expression further might be a different topic.

[HaloFour]

A return keyword within a block already means something. The lack of assignment to a variable should not affect that meaning.

[gregsn]

int foo()
{
  var x = { return 0; } // block expression, foo is not returning here
  beep();
}

int foo()
{
  { return 0; } // block statement, return from foo
  beep(); // no beep
}

int foo()
{
  Func<int> a = () => { return 0; }; // foo is not returning here
  var x = a();
  beep();
}

return doesn't change its meaning by being used inside another code block. It's just now scoped to that code block and returns from out of there. This is excepted as it is expected that a nested break is unable to break out of an outer loop.

it's not confusing as it is easy to explain: it behaves like a local function with its pros and cons. #1167 (comment)

[HaloFour]

@gregsn

That is changing its meaning. Currently return within a code block returns from the function in which it is declared, but you're proposing that it "returns" from the code block if the "block" is assigned to a variable. The fact that you are or aren't assigning an expression to a variable doesn't change the behavior of an expression, nor should it here.

[gregsn]

@HaloFour
only certain expressions can be used as statements. A block expression wouldn't be an expression that can be used as a statement. {} already have a meaning at places where a statement is expected. It's a block statement and it's meaning is defined.
This, however, doesn't mean that we can't invent a block expression that now takes care of the return. Similar to what C# language designers have done when adding lambda expressions.
0; this expression can't be used as a statement.
{ return 0; } neither. But luckily it is clear that the programmer clearly wants to do something different... it is just a code block statement.

[HaloFour]

@gregsn

Indeed, not all expressions can be statements and not all statements can be expressions. But you're proposing to use an existing statement syntax for use as an expression, and to subtly change the behavior of certain keywords within the block of that expression. With lambdas and local functions you have to use completely new syntax to surround the body.

The language team has proposed and championed an alternative syntax for these kinds of expressions:

#973

[gregsn]

@HaloFour
thanks for the clarification!

note, however, the author of this proposal says:

PS: I suggested this as an alternative under sequence expressions but I figured they are actually very different features and make sense beside each other. (I suspected this is a dup but couldn't find any)

Having a return statement within a block (several times) feels different than a "declaration expression" that returns the value of the final expression within the block.

But for me, this #973 works well. Those expressions, of course, are primarily for allowing brevity of expression.