Allow expression bodied foreach and for

[banjouuid]

Currently this is allowed:

private void Test(IEnumerable<int> numbers) { foreach (var number in numbers) Debug.WriteLine(number); }
But this is not

private void Test(IEnumerable<int> numbers) => foreach (var number in numbers) Debug.WriteLine(number);
It would be nice if we can expression body this scenarios too.

[alrz]

With #101 you can do this:

private void Test(IEnumerable<int> numbers)
  => from number in numbers do Debug.WriteLine(number);

[Joe4evr]

To be clear, this isn't "Allow for/foreach to have an expression body" (that would actually increase character count for a single statement), but rather "Allow for/foreach as an expression".

And even when do for query syntax is added, this would be nice to have if only for symmetry.

[HaloFour]

I don't think it makes sense to make for/foreach an expression. That would have a very wide impact on the language. Rather I think it might make sense to instead consider single statements as valid in the context of the lambda => operator so that they can be used in expression-bodied members or in simple Action-like delegates.

However it's not like this rule prevents you from solving any problems and at most the verbosity is only increased by two characters in the case of a lambda.

[banjouuid]

@Joe4evr I agree.

it would be nice if we could have also something like:

public void Test() => if(true) Debug.WriteLine("Test");

[CyrusNajmabadi]

Another way to think about this is that currently the language allows:

construct => expr ;

i.e.

void Foo() => expr; or
int Prop => expr;

We could think about reformulating this as:

construct => statement

With this formulation, the existing constructs still work, as they would be:

construct => expression_statement

And users would then be able to other statements as well like:

construct => foreach ...

That said, i personally don't like this idea and wouldnot be championing it myself :)

[lachbaer]

@banjouuid

it would be nice if we could have also something like:
public void Test() => if(true) Debug.WriteLine("Test");

Yes, that's much shorter and better than public void Test() { if(true) Debug.WriteLine("Test"); } 😁

But where I agree is that expression bodies are probably mainly used in short expressions. When there are some short bodies in a row mixing block body and expression body syntaxes just because one goes so and the other goes so simply doesn't look nice. Because not less people like the expression syntax much - count me to them, too - it'd be really nice to extend some constructs to them.

In my regard, the query syntax could be extended for such purposes nicely, like e.g. the already mentioned #101, because that implicitly gives the possibility to return a calculated value by using select.

int Sum(int count) => from i in (int j=0; j<count; ++j) do { result += i; } select result;
// (or similar)

[bondsbw]

@alrz

With #101 you can do this:

private void Test(IEnumerable<int> numbers)
 => from number in numbers do Debug.WriteLine(number);

@gafter previously stated that the expression form was not an intended part of that proposal.

And your suggestion above is inconsistent with your discussion at #101. Above it presumably is an expression of type void, while at #101 it is used to form a non-void expression with implicit-dot syntax:

var x = 
    from item in collection
    where item.foo
    select item.bar
    do Single();

(I'm not disagreeing with the idea, just pointing it out in case you would like to include the new form in the other proposal.)

[aluanhaddad]

public static void ForEach(this IEnumerable<T> items, Action<T> action)
{
    foreach (var item in items)
    {
        action(item);
    }
}

private void Test(IEnumerable<int> numbers) => numbers.ForEach(Debug.WriteLine);

do query termination would be useful, although not terribly, because it enables consuming a query expression without needing to declare additional variables to store the query and to reference each element and without needing breaking from LINQ syntax.

That is

from number in numbers where number % 2 != 0 do Debug.WriteLine(number);

vs

foreach (var number in from number in numbers where number % 2 != 0 select number)
{
    Debug.WriteLine(number);
}

[Thaina]

I was proposing extension method for that and they would name it Do() if they would make it

https://github.com/dotnet/corefx/issues/19698

[aluanhaddad]

@thania I absolutely agree that if a do syntax is added to query comprehensions then it should have a corresponding method form that defines its implementation and that can be implemented to customize the behavior, just as is the case for the majority existing operators.

I am however inclined to agree with @svick's reservations regarding side effects within queries. In particular, I think this method should be void

[alrz]

@bondsbw

You're right, yet it's a "do query termination" but in the expression form. I'll update my comment.

[Scepheo]

@CyrusNajmabadi

We could think about reformulating this as:
construct => statement
With this formulation, the existing constructs still work, as they would be:
construct => expression_statement

This makes sense in the context of expression-bodied property setters, though. Currently, this is allowed:

private void WriteAll(int[] numbers)
{
    foreach (var number in numbers)
        Console.WriteLine(number);
}

public int[] Numbers
{
    set => WriteAll(value);
}

Where WriteAll(value) is an invocation-expression which returns void, which "is permitted only in the context of a statement_expression or as the body of a lambda_expression"¹. The latter refers to an anonymous_function_body, where it can also only appear as a statement.

I suspect I'm either missing something or looking at an outdated spec here though, as the spec on this github doesn't appear to mention expression-bodied getters and setters either.

1: https://github.com/dotnet/csharplang/blob/master/spec/expressions.md#invocation-expressions

[Joe4evr]

I suspect I'm either missing something or looking at an outdated spec here though

The spec so far is indeed outdated. Have a look at this comment for the details.