Proposal: sequence expressions

[orthoxerox]

As previously described here: dotnet/roslyn#6182

A prototype available here: https://github.com/orthoxerox/roslyn/tree/features/statement-expression

Statement expressions

Summary

Expressions can contain additional intermediate statements, including temporary local variable declarations.

Motivation

They work well with the ternary operator, base and this constructor calls and potential match expressions.

They also can be lowered into (good for function pipes) (if the binder map can survive this, haven't investigated that yet).

Detailed design

See here: dotnet/roslyn#6182

At the moment I cannot access the markdown of the formal syntax of the proposed syntax, but it's an open paren, 1+ statements, an expression, and a close paren. Only declaration and expression statements are allowed. The value is the value of the expression.

Locals declared in the statements do not leak outside the statement expression.

Drawbacks

People will abuse it and turn their ?: into an unreadable mess.

Alternatives

Blocks and if statements could be changed to return values if their last statement is an expression statement or an if statement or a block that return a value.

Unresolved questions

What should happen to out vars and pattern variables declared in the expression? Are there any compelling use cases to make expression statements leak them?

Should we allow more statement types to be used inside statement expressions? Why?

Design meetings

None yet.

[DavidArno]

Thoughts:

x is T y scope leakage will conflict with this

As @alrz points out in Roslyn #6182, this proposal would cause inconsistencies between scope leakage for expressions:

var x = (var y = SomeThing(); y is int z ? z : 0);
// z leaks into scope here; y doesn't.

As it's not possible to access z in that outer scope, changing the rules around scope leakage for is patterns would not be a breaking change though, so this would be an easy fix.

"silly programs/noise reduction argument

In Roslyn #6182, @qrli argues that folk could use this to write "silly" functions like:

public double Foo() => (
   var a = GetSomething();
   Log(a);
   DoSomething(a)
);

I'd argue that this isn't silly. Whilst not traditional style C#, it does fit with the more functional style that some of us prefer to write. The above removes the need for the "noise" of the return statement if it were written in a traditional style and thus would be a good thing:

public double Foo()
{
   var a = GetSomething();
   Log(a);
   return DoSomething(a);
}

[orthoxerox]

@DavidArno re: silly programs

That's why I wrote that the alternative is to turn blocks into expressions. This upends every single tree node hierarchy in Roslyn, so the cost-to-benefit ratio is not attractive, but it's theoretically doable.

[DavidArno]

@orthoxerox,

Yep, saw that. Still thinking through the implications though, so I didn't comment on it. I really like that idea, but feel there's got to be a downside that I haven't thought of yet. 😀

[qrli]

@DavidArno re: scope leakage
For reference, I proposed roslyn#15651 to solve the leakage

[DavidArno]

@qrli,

Good point; I'd forgotten about that. There are issues with it, as the comments discuss, but it's a good starting point for discussion at least.

[orthoxerox]

@qrli as implemented right now, statements do not leak any declaration outside the scope, I copied the scoping rules from blocks. I am not sure if the terminal expression leaks anything (it shouldn't), but I finally passed the basic happy path test at 2am, so I was in no state to investigate further.

It can either leak or contain pattern and out variables, it's a design and implementation issue, not a blood-brain barrier.

[gafter]

I think a more realistic alternative to this proposal would be local functions.

[alrz]

Is dotnet/roslyn#6182 off the table now?

[gafter]

@alrz dotnet/roslyn#6182 does not have an LDM champion at the moment.

[jnm2]

#377 apparently supersedes this.