Proposal: return, break and continue expressions

[alrz]

Ported from dotnet/roslyn#14239

return, break and continue expressions

Summary

Lets you use return, break and continue as an expression.

Proposal

Since throw is now an expression, I think return , break and continue are also good candidates to be an expression.

var c = obj as C ?? return;
// instead of
if(!(obj is C c)) return;


var o = F() ?? return;
// instead of
var o = F();
if (o == null) return;

var (foo, bar) = GetFooBar() ?? return; // `GetFooBar` returns a nullable tuple
// instead of
if (!(GetFooBar() is var (foo, bar))) return;
// or
if (!TryGetFooBar(out var foo, out var bar)) return;
// or 
var result = GetFooBar();
if (result == null) return;
var (foo, bar) = result.Value;

foreach (var item in list) {
  var result = item match {
    case 1: "one",
    case 2: "two",
    case 3: break,
    default: continue,
  };
}

There is no straightforward alternative for the third example as you will need to use the switch statement.

Open question: throw expressions are not allowed as the RHS for && and ||. should that also be applied here?

Unlike throw, these expressions need to return a value,

void F(out int i, out int j) {
  (i, j) = condition ? (1, 2) : return;
}

EDIT: We could make this specific example an error as suggested by @lostmsu.

Open question: should we allow yield break and goto as an expression? (yield return is excluded because it is not a jump instruction).

[Logerfo]

Combined with #102, we could get really objective code, like this one:

R M(object obj)
{
	var c = obj as C ?? return default;
	//...
}

Which would be equivalent to the code below with current language specs:

R M(object obj)
{
	if(obj is C c)
	{
		//...
	}
	//else not needed since we suppose there is a return inside the if block
	return default(R);
}

Which is far more objective than what we had using c# 6.0:

R M(object obj)
{
	var c = obj as C;
	if(c == null)
		return default(R);

	//...
}

[gulshan]

This feature will encourage mixing imperative and functional programming styles. That can turn out to be a bad idea IMHO.

[alrz]

Not sure how is this functional but mixing imperative and functional programming were never considered a bad idea and in fact it's one of the fundamental design directions that C# follows.

[gulshan]

This code contrasts among different coding styles-

// Functional
var res1 = list
    .TakeWhile(n => n != -1)
    .Aggregate((i, j) => i + j);

// Imparetive
var res2 = 0;
foreach (var n in list)
{
    if (n == -1) break;
    res2 += n;
}

// Mixed, enabled by this proposal
var res3 = 0;
foreach (var n in list)
{
    res3 += (n != -1) ? n : break;
}

In functional style, everything is an expression. Where as in imperative style, everything is a statement. In functional languages loops are avoided and recursion is the way of repeating some task. While F# does allow loops, break and continue are not allowed. C# allows both styles. While mixing them is possible, not very intuitive now and people will gravitate towards either of the styles. But this proposal will enable more freestyle mix-up.

Newly added throw expression in C# corresponds to failwith expression in F#. And exceptions should be exceptional. I also want to quote comment by @gafter when this was first proposed within the discussion dotnet/roslyn#5143 -

throw is not a control statement in the same sense as continue and break, and they make less sense in an expression context.

[HaloFour]

One of the things that I like about the potential of using continue and break in expressions is the possibility of also extending LINQ query syntax to support them where they could translate into Where and TakeWhile respectively.

var query = from n in list
    select n ==  1 ? "one"
         : n ==  2 ? "two"
         : n == -1 ? break
         : continue;

// translates into

var query = list.Select(n =>
                  n ==  1 ? (true, true, "one")
                : n ==  2 ? (true, true, "two")
                : n == -1 ? (false, true, default(string))
                :           (true, false, default(string)))
    .TakeWhile(tuple => tuple.Item1)
    .Where(tuple => tuple.Item2)
    .Select(tuple => tuple.Item3);

As for the argument regarding imperative v. functional programming, most developers don't think in such black and white. A functional feature in an imperative language isn't inherently a bad (or good) thing. And while it's true that not everything is an expression in imperative languages, many things still are. Beyond the idealistic argument, I can understand that it might be difficult to discern that an expression could affect the flow of the containing code if a control clause is buried deeply within. But I don't think I'd doom the entire proposal based on what a bad/"clever" programmer can do to abuse it.

[Thaina]

Not oppose the idea just present what I normally did

void M(object obj)
{
    foreach (var item in list.Where((item) => item >= 1 && item <= 3).TakeWhile((it) => it != 3))
    {
        var result = item == 1 ? "one" : "two";
    }
}

// Actually I would like to explicit if break from the first line
void M(object obj)
{
    foreach (var item in list.Where((item) => item >= 1 && item <= 3))
    {
        if(item == 3)
            break;

        var result = item == 1 ? "one" : "two";
    }
}

Well, I think this feature has too many alternative

[lachbaer]

Proposal #135 could actually come in handy here, as well.

[alrz]

Since return would be allowed in a null-coalescing operator,

foreach (var item in list ?? return)

I wonder if we could abuse break in that context to "skip" the loop instead of early return.

foreach (var item in list ?? break)

[lachbaer]

I don't see where

foreach (var item in list ?? return) {
...
}

would be more comfortable than putting a conditional return statement in the loop itself

// ** example is wrong ** just left for documentation
foreach (var item in list) {
    if (item == null) return;
...
}

Latter is even more intuitive to read. What binding does it actually have? To me it is a bit arbitrary.
Binding issue solved. But it should be written in braces, so that it is is clear to a not knowing reader.

// not this
(var item in list) ?? return
or
// it's this
var item in (list ?? return)

BTW, goto should also be added to the list for the sake of completeness. So all non-linear "jump" statements are respected.

[alrz]

@lachbaer

Latter is even more intuitive to read.

Except that it will throw. You probably want to write it before the loop.

Equivalent code of ?? break would be actually a little messier.

if (list != null)
{
  foreach (var item in list)
  {
  }
}

Embedded statements can make this less verbose but I would certainly prefer ?? break over that.

What binding does it actually have?

foreach accepts an expression after in, so it is not arbitrary at all. In fact, you can already write this:

foreach (var item in list ?? throw new Exception(..))

But it's useless, because you are just converting a NRE to another exception.

goto should also be added to the list for the sake of completeness.

I don't disagree, but I just didn't find any sensible use case for it. Personally, I try to not use goto beyond goto default; which is actually nice.

[benaadams]

Or

foreach (var item in list ?? emptyList)
{
    // ...
}

[alrz]

@benaadams

If list is an array, yeah, that might be good enough, but with any other IEnumerable, you might seem a little apathetic to performance.

[lachbaer]

I don't disagree, but I just didn't find any sensible use case for it. Personally, I try to not use goto beyond goto default; which is actually nice.

I don't use goto as well (except for debugging purposes), but despite liking or not it has its usage cases. But as it is a flow breaking statement, like return, break, continue and throw, this one should also be respected.

I like this proposal. C# has already come so far and there are already so many ways to reach the goal, including functional vs. imperative approaches, LINQ, wse. I think that there surely will be definite use cases for it where it will improve reading or the process of writing.

There are many that prefer not to jump out of a block in the middle! That also is probably just a matter of taste and personal experience. I would recommend to specially syntax highlight the occurences of these keywords in code editors, whether standing allone or being part of a longer expression!!!! (There are already extensions, but it should be standard).

[lostmsu]

Just wanted to note, that return expression is no-brainer: just like throw expression it always leaves current method, so there's no need to worry about what value does it have.

[alrz]

@lostmsu See the example in the OP with out parameters.

[alrz]

@HaloFour

Agreed, since we should correspond continue to the outer loop anyways, it wouldn't be consistent to treat break differently. Without touching the binder, it will behave just like what you described.

[HaloFour]

@alrz

Sounds good. Kind of a shame that it couldn't be used to skip the current enumeration. Maybe goto expressions? Or if C# gets break/continue labels?

foreach (var foo in bar ?? goto label1) { ... }
label1:

label2: foreach (var foo in bar ?? break label2) { ... }

[jnm2]

@HaloFour what's the difference between a break label, a continue label, and a goto?

[HaloFour]

@jnm2

Avoids the goto keyword, mostly, to which some people have a severe allergy. Beyond that the difference really lies in the position of the label. In Java, the label always goes immediately before the loop and using break label or continue label would either break out of or continue iteration of that loop from within a nested loop.

Java Branching Statements

[ashmind]

@HaloFour

Kind of a shame that it couldn't be used to skip the current enumeration.

There is always a possibility of future foreach? in the mold of #35, so this doesn't have to cover it.

[Logerfo]

@HaloFour I totally didn't know about Java Branching Statements. Is there something preventing C# to have this kind of features?
Also, I like the way php deals with this.

[HaloFour]

@Logerfo

Is there something preventing C# to have this kind of features?

Desire? Philosophy? C# has the feature, just with different syntax. The only reason to suggest implementing Java's syntax is disliking having to use the keyword goto. Not that I'm arguing against having a more structured form.

[Logerfo]

goto does work for the break case, but, as far as I know, not for the continue one.

[HaloFour]

@Logerfo

You're right. It can be accomplished through a combination of other things, such as break or goto out of a nested loop and checking a flag, but it's certainly not as succinct as a branched statement or labeled loop.

[AndreasHassing]

I'm carefully optimistic about this idea. I often find myself writing boilerplate code such as:

var user = await userManager.GetUserAsync(User);
if (user == null) { return RedirectToLogin(); }
// or
var thing = await thingService.GetThingAsync(id);
if (thing == null) { return RedirectToIndex(); }

Which, with this proposal, could be:

var user = await userManager.GetUserAsync(User) ?? return RedirectToLogin();
// or
var thing = await thingService.GetThingAsync(id) ?? return RedirectToIndex();

I think it reads quite nicely, and the verbosity from what I have now is not helping here.

[momvart]

Is this proposal going on in another thread? I wonder why it is inactive despite the fact that it is one of the most useful features.

After the addition of support for throwing exceptions in the null-coalescing operator, I was anticipating return statements to be added either. But after three years, it seems that it is not even one of the champions.

[OFark]

I have a different take on this proposal and swapped the syntax around.

basically:
return if thing is null : null
or
return if thing.IsInvalid : new InvalidResponse();

so it's like the 'else if' statement

foreach(var item in items)
{
    continue if item.Value < 3;

    // do otherthings with Value >= 3;
}

[OFark]

There's a group of devs that would say that if statement should have braces

if (item.Value < 3) 
{
   continue;
}

It was a conversation about this very thing that lead to my proposal for a condition for the return statement.

[OFark]

There is also the code smell of if statements inside if statements. The suggestion being break it out into another method, but you can't very well issue a return from inside the method called.

[HaloFour]

There's a group of devs that would say that if statement should have braces

There's a group of devs that would say that return if and the like are confusing because they push the conditional off of the visible part of the screen. In fact that is exactly why this proposal hasn't advanced. The language can't invent a dozen different ways to do the same thing because each team has their own stylistic preferences.

There is also the code smell of if statements inside if statements.

There's no code smell in nesting if statements or embedding control statements within conditionals. That is idiomatic C#.

[Thaina]

There has been similar discussion in #138 (comment)

And also dotnet/roslyn#11562

[HaloFour]

And: #2195

[davidnmbond]

This feature makes the code more succinct and its intentions are clear. What's not to like?

[CyrusNajmabadi]

Folding labeled break/continue (#6634) into a bucket with this may make improve the chances of these being done.

[noptools]

I agree. Another example in a method with void return type:

var x = n switch
{
1 => DoOne(),
2 => DoTwo(),
_ => return
}

(Should I start another 'discussion' to make this a 'proposal'? Is there already one out there?)

[CyrusNajmabadi]

That would be covered under this proposal.

[DavidArno]

@noptools,

See #3038, #3037, #2632 and #2860. It's a popular request 😃