LDM Notes for August 28th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-08-28.md

Agenda

• Nullable in ref ternaries
• Block-bodied switch expression arms

[timcassell]

${ yield value; } syntax wasn't brought up for expression blocks? It closely resembles Java's switch expressions (minus the $ part).

[xparadoxical]

To me yield is associated only with iterator methods and enumerables/enumerators, but without break/return it has no formal meaning and wouldn't be nearly as confusing as break value; and return value;. It's also better than out in that it already starts statements, while the place of out is in param/arg lists.

[333fred]

It came up in passing, but we didn't dive into pros/cons.

[huoyaoyuan]

yield value feels like producing multiple values from the expression block and similar to yield return.

[BreyerW]

@huoyaoyuan where it works today it can but doesnt have to though and as such is still decent alternative imo to all others that have their quirks (eg. dropping ; is too subtle especially in C# which has very few such subtleties unlike some of languages, return is confusing since it means quitting method entirely now etc.)

[qrli]

I think we can just spell out the new scope to break from - basically "break expression value;", or "break switch value;" if you like.

While return breaks from a function body, break only break from the parent, unlike Java's. Instead of copying the "break label;" of Java, C# can choose to extend break with a scope indicator. And naturally, the scope indicator can be for, foreach, switch, or even try, catch, etc. So we could have break switch, break foreach, break try...

[huoyaoyuan]

Two keywords are really verbose. Further more, how would it work when there's no control-flow to break?

[qrli]

Two keywords are really verbose.

I'm addressing the concern that "break value;" and "out value;" may be confusing. I don't think there is an existing keyword can be clear enough, thus using 2 may address the confusion, just like "yield break". Personally, I'm fine with "break value;" and "out value;".

Further more, how would it work when there's no control-flow to break?

Sorry I don't get the question. Why is control-flow necessary?

[timcassell]

It's not strictly necessary, but it's better to leave the possibility open in the future.

[alrz]

some members are concerned about the confusion it could bring if you mix break, break value, and continue

I think the fact that you'd get an error on misusages can address teh confusion

int m;
switch (e) {
  case a: M(); m = 1; break;
  case b: M(); m = 2; break;
  default: M(); m = 3; break;
}

There's really no other way to do this even if it's inside a loop or there's some artibrary return statements,

int m = e switch {
  a => { M(); break 1; }, // could simplify to `{ M(); 1 },` when there's a single break at the end
  b => { M(); break 2; },
  _ => { M(); break 3; },
}

Something that is left out of the discussion is the same improvement for switch statements,

switch (e) {
  case a => { M(); m = 1; };
  case b => { M(); m = 2; };
  default => M();
}

I think that is discussed in #3038 but supposedly all would be built on top of block-expressions even if they wouldn't be allowed anywhere else.

[DavidArno]

It would also preclude the possibility of an expression block from being able to return a value from the enclosing method in the future.

int M(int x)
{
    try
    {
        return SomeSlowMethod({ var y = ComputeValue(x); if (y == 0) throw new ReturnFromMethodException(0) else return y; });
    }
    catch (ReturnFromMethodException e)
    {
        return e.Value;
    }
}

🙈

[CyrusNajmabadi]

It would also preclude the possibility of an expression block from being able to return a value from the enclosing method in the future

I think ldm already rejected a variant of that idea when we rejected expression level return/break/continue.

[HaloFour]

I think ldm already rejected a variant of that idea when we rejected expression level return/break/continue.

They rejected return/break/continue expressions. This would be return/break/continue statements within an expression block. Given the entire point of an expression block is to contain multiple statements, and most of those statements can't be used in expressions today, I don't see why the one decision necessarily implies the other.

If that ultimately is the decision of the LDM, that's fine. I'd still have qualms with return in an expression block as I feel that'd be confusing, but I also recognize that going down this path and trying to blur the lines between the blocks and the constructs containing those blocks (namely methods and lambdas) sort of leaves statement blocks as the odd feature out.

[jnm2]

I would love to consider return inside an expression returning from the method, along with break/continue breaking a containing loop, and even revisit ?? return/break/continue in light of this.

[DavidArno]

@jnm2,

I don't think that having return within an expression-block just return to the outer scope would preclude that. Contrived code that tries to illustrate this:

List<int> PrimesOnlyNoZerosAllowed(List<int> source)
{
    List<int> primes = [];
    foreach (var i in source)
    {
        var isPrime = i switch {
            0 => return [], // returns from method
            x when x % 2 == 0 => break, // breaks within the foreach
            x => { 
                var isPrime = IsPrime(x);  
                if (isPrime) LogPrime(x);
                return isPrime; // returns value from the expression to the switch arm
            }
        };

        if (isPrime) primes.add(i);
    }

    return primes;
}

Whether such behaviour is desirable is up for debate, but I think it shows that this feature need not preclude having return, break and continue supported in switch/ternary expressions.

[TahirAhmadov]

I definitely don't like return, and somewhat dislike break. My 2 cents

[DavidArno]

It'll be interesting to see what use cases the team come up with for these block-bodied expressions. From experience, the only time I wish such a thing existed is when I want to perform some sort of assignment or deconstruct and then perform some function on those new variables. So for me, the value would always be at the end of the block and therefore z = {var (x, y) = Foo(); Bar(x, y)} suits me nicely. The question "how might a user produce a value from the middle of a foreach..." is a moot one I feel as it just doesn't figure as a viable use case for me.

Others likely have different experiences though, so I'm intrigued where this feature goes next.

[CyrusNajmabadi]

Without the semicolon, it no longer is a statement

A major challenge here, to me, is such a change in semantics over something so minor.

This was why, for example, I found JSs optional semicolons (and the strangly different semantics you would get if one was present or not) as a mistake.

[HaloFour]

Without the semicolon, it no longer is a statement

There's nothing about semicolons (or the lack thereof) that implies that a statement would become an expression, not to mention it would be a very subtle difference for such a big change in how the block is interpreted.

[DavidArno]

There's nothing about semicolons (or the lack thereof) that implies that a statement would become an expression...

I am confused by this statement. I posted a link to the proposal that details how removing the semicolon "...implies that a statement would become an expression...", so to my mind, this comment by you is nonsense. But four people - including two members of the language team - have upvoted it, so it must make sense to them. Perhaps you could rephrase for me so I might understand too?

... not to mention it would be a very subtle difference for such a big change in how the block is interpreted

That is certainly the disadvantage of this approach. On the plus side, it's a simple syntax change that achieves the objective of allowing statements within an expression. On the down side, it is risky in terms of readability. I personally think the pros outweigh the cons here, but I can understand why you feel the opposite.

[CyrusNajmabadi]

so to my mind, this comment by you is nonsense

There's nothing intrinsic to c# that makes this the case. Yes, we acknowledge we could make it work this way in the future. But, as you've seen, it comes with a host of issues.

The key part is 'implies'. We like the past of the language to help guide and imply how people think about the future when possible. The language up till now has not worked this was. So there's no implication that it would in the future (even if it's technically possible).

[DavidArno]

Thanks, Got it now.

[dersia]

I am still in favor of out and don't quite understand how this could be confusing. out is today only allowed in for parameters so having it inside a block would be completely new and couldn't be confused for anything else.

as a reviewer looking at code that uses either of yield, break or return in side a block could be confusing and I would need to look very deeply into the code to understand what those are referring to, but out on the other hand would be a no-brainer because it couldn't be used like this before, so there is only one thing this could mean, no ambiguity, no misunderstanding.

anyhow, I appreciate that out Was considered by the ldm, though I can't fully understand the confusion there.

[HaloFour]

as a reviewer looking at code that uses either of yield, break or return in side a block could be confusing and I would need to look very deeply into the code to understand what those are referring to, but out on the other hand would be a no-brainer because it couldn't be used like this before, so there is only one thing this could mean, no ambiguity, no misunderstanding.

The same is true of break. It can't be used with an operand today, so it could only mean one thing.

Ultimately there is no existing keyword that fits well. Java literally just went through this same design process and decided to add a new keyword yield because the other alternatives felt clunky and unintuitive, and I very much agree with them.

[dersia]

I agree, there is no keyword that fits well.

but I still think that there is a difference in using an keyword that is used in similar parts of the language like return, yield or break (those are all valid on blocks today) compared to keywords that have never been used in similar places. I acknowledge that break with an operand is illegal in the language today, but since break itself is legal, I fear that it could be as subtle as leaving out the last semicolon during a review and could be mistakingly be overseen.

in any case, I would prefer break x; right after out x; over any other suggestion I have read so far.

Maybe a completely new keyword (take, emit, fetch, elect, select, choose, pick, adopt, exchange, report, bounce or just data) would be just the best and easiest solution.

[BreyerW]

What about echo ?

[colejohnson66]

echo implies outputting to a console, possibly for pipelines. I've never heard of it being used in the context of expressions.

[hypeartist]

What about scoped break? Both keywords exist already and scoped fits nice into the concept

[qrli]

To attack from a different angle:
C# already has a way to do expression block without any new invention on keywords, by reusing lambda e.g.

void Foo(int a, int b)
{
    var bar = ((Func<int>)(() => { Baz(); return a + b; }))();
    ...
}

If we clean up the clutter (as the lambda is immediately invoked and discarded), it would ideally be something like:

void Foo(int a, int b)
{
    var bar = () => { Baz(); return a + b; }(); // not legal today
    ...
}

Essentially, it can still be treated as a lambda, so return won't cause confusion.

For switch expression, it would be like:

var bar = a switch {
    0 => { Baz(); return a + b; }(); // not legal today
    ...
}

To use it outside of switch, of course, there is still some cluster. If we say the () => part can be omitted, then it would be like:

void Foo(int a, int b)
{
    var bar = { Baz(); return a + b; }(); // not legal today
    ...
}

[DavidArno]

This is an interesting approach to the problem. Curiously though, you still arrive at almost the same solution that has been proposed elsewhere. If we take the view that that () at the end of the block can be improved by taking a "Poka Yoke" approach by moving the syntax that says "this is an implied self-executing lambda" at the beginning:

void Foo(int a, int b)
{
    var bar = ${ Baz(); return a + b; };
    ...
}

And then the return really isn't needed as it is an expression and so has to have a value at the end unless it early returns:

void Foo(int a, int b)
{
    var bar = ${ Baz(); a + b; };
    ...
}

This then neatly solves a much requested feature too: simplified fluent methods:

public ThisType FluentThing(int a, int b) => ${ DoSomethingWithArgs(a, b); this; };

I'd personally also remove the ; after this, but that seems unpopular here.

[qrli]

@DavidArno While I agree may look terser to omit return, my experience with Powershell on the very same syntax is really bad. When a if body is a function which returns a value but commonly discarded, it acts like return. Of course, Powershell allows returning multiple times, which produces even more curious bugs. So I'd rather not save the return or whatever keyword here.

[DavidArno]

@qrli, that is a really good point. I've been caught out by that aspect of PowerShell on more than one occasion. I think you just convinced me to flip my position on this to definitely wanting a keyword, eg return 👍

[jnm2]

Borrowing a leaf from raw string literals, the number of curly braces introducing the sequence expression could tell you how many parens to wrap the expression in that becomes the result.

var x =
{{{
    using var y = ...;
    (((y.Z)))
}}};   

(((🙃)))

[ufcpp]

""" was not valid in C# <10, but {{{ }}} is valid.

[jnm2]

Great point. Thankfully, this was not a serious suggestion on my part :D