[Proposal]: Inlined enumeration as function argument expression

[Rekkonnect]

Inlined enumeration as function argument expression

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

This syntax should provide a faster way to call a function for each element in an enumerable object.

Motivation

The main motive behind this syntax is simplifying the code that is required to properly enumerate through a collection of objects and only call one function within. In other words, this aims to simplify the process of performing a single operation on a collection of objects.

Detailed design

Assuming that an operation is performed like so:

foreach (var x in items)
    Function(x);

the new syntax simplifies this code into:

Function(foreach in items);

This skips the need for introducing a temporary variable into the mix, as its only purpose is to be used once.

---

For functions with multiple arguments, the foreach in statement should be placed before the collection whose iterated elements are intended to be used as an argument at the desired position. For instance:

foreach (var x in items)
    Function(1, x);

becomes:

Function(1, foreach in items);

---

Multiple foreach in can be allowed per single function call, but it becomes the equivalent of nesting each foreach loop in each other. Example:

foreach (var x in itemsX)
    foreach (var y in itemsY)
        Function(x, y);

becomes:

Function(foreach in itemsX, foreach in itemsY);

---

Multiple foreach in can also be present in params args. Example:

// assume the function:
void Register(params Item[] items);

// usage code:
foreach (var x in itemsX)
foreach (var y in itemsY)
foreach (var z in itemsZ)
foreach (var w in itemsW)
    Register(x, y, z, w);

becomes:

Register(foreach in itemsX, foreach in itemsY, foreach in itemsZ, foreach in itemsW);

---

Nested and chained function call expressions are also supported.
An example of a chained function call expression:

foreach (var c in chars)
    stringBuilder.Append(c).Append(' ');

becomes:

stringBuilder.Append(foreach in chars).Append(' ');

And an example of a nested function call expression:

foreach (var loc in locations)
    Register(Invert(loc));

becomes:

Register(Invert(foreach in locations));

---

There is also the ability to apply this for IAsyncEnumerable objects, by using the await foreach in variant. Example:

await foreach (var x in items)
    Function(x);

becomes:

Function(await foreach in items);

Drawbacks

This syntax does not break compatibility with other rules. It is however a relatively niche feature, and despite it not requiring changes outside Roslyn itself, it could not prove worthy of existing.

One issue is from supporting multiple foreach in in a single call, which may increase line size for cases when more than 2 are used, sacficing code readability.

Alternatives

Another proposed design is only offering a shorthand for:

foreach (var x in items)
    Function(x);

into:

Function foreach in items;

Same conditionals apply, but this syntax only works for functions that take exactly one argument. It is not clear if nested or chained function call expressions can be supported, or what new features and syntax would have to be introduced for that to work.

Unresolved questions

None yet.

Design meetings

None.

[HaloFour]

IMO, this makes it painfully easy to miss the fact that an enumeration is happening and that the method is invoked multiple times. It's also very unclear what happens in the case of a fluent API, does the method get called on the return value or on the original target? If the latter it wouldn't work at all with immutable type builders.

This feels like an awful lot of voodoo and for minimal savings. There's little appreciably different between:

Register(Invert(foreach in locations));

and

foreach (var loc in locations) Register(Invert(loc));

And it's much clearer how the latter will behave.

[Rekkonnect]

IMO, this makes it painfully easy to miss the fact that an enumeration is happening and that the method is invoked multiple times.

The presence of foreach alone should be sufficient to denote that something's being enumerated.

It's also very unclear what happens in the case of a fluent API, does the method get called on the return value or on the original target? If the latter it wouldn't work at all with immutable type builders.

It was specifically declared that the order of the nesting and chaining is taken into account. All examples provide the relation of the current vs the proposed syntax, without altering the result of the execution.

This feels like an awful lot of voodoo and for minimal savings.

It might indeed appear cluttery, but personally, putting two lines of code in one is a bigger sin. I always ensure that I break the statement in the way they should normally appear like in the provided examples.

[canton7]

Yeah, but it loons like one of the arguments is being enumerated in some way, and a result passed to a single invocation of Function. It reminds me of a Python list comprehension being passed to a method call.

[HaloFour]

The presence of foreach alone should be sufficient to denote that something's being enumerated.

Which can easily be lost in the middle of a relatively long list of parameters.

It might indeed appear cluttery, but personally, putting two lines of code in one is a bigger sin. I always ensure that I break the statement in the way they should normally appear like in the provided examples.

That's a style preference. The language doesn't care if you put them on a single line or eight. But if your intent on breaking those two statements onto multiple lines is to make it more clear that the iteration is happening then you're very unlikely to want to use a foreach argument modifier which makes that iteration substantially less apparent.

[Rekkonnect]

Which can easily be lost in the middle of a relatively long list of parameters.

That's true, and it is not encouraged to be used in such cases. The motivation section explains the reason well enough, discarding the need to repeat it.

But if your intent on breaking those two statements onto multiple lines is to make it more clear that the iteration is happening then you're very unlikely to want to use a foreach argument modifier which makes that iteration substantially less apparent.

My intent is to oblige with the syntax and not convolute the line with all that information. In a standard simple foreach you've got the statement, which consists of a variable declaration, including its name, the enumerated collection, and the usage of the enumerated elements, usually through a function, which also declares that the temporary variable is included.

This new syntax gets rid of the declaration and naming of a temporary variable that holds the enumerated element. The produced result only consists of the action, the indication of an enumeration process and the enumerated collection. It's also flexible enough to allow other arguments to exist in the call, without invalidating the syntax in the case of a function that has more than 1 arguments.

[Youssef1313]

This new syntax gets rid of the declaration and naming of a temporary variable that holds the enumerated element.

What about Array.ForEach(items.ToArray(), Function)?

[Rekkonnect]

What about Array.ForEach(items.ToArray(), Function)?

ToArray should be avoided for simply enumerating due to performance concerns.

LINQ does provide a ForEach function for IEnumerable, but it's still a LINQ function. Furthermore, it's also not as optimal due to the requirement of passing a delegate.

[Rekkonnect]

You're missing the whole point of the feature proposal.

[bernd5]

No, I do not.

Your code:

Function(foreach in items);

could be written as:

items.ForEach(i => Function(i));

This is very clear and works today. The only downside is, that without compiler supports this needs to use a delegate...

But without changing the syntax it could be rewritten to:

foreach (var i in items)
{
    Function(i);
}

See for example the following project:
https://github.com/antiufo/roslyn-linq-rewrite

So I think this is just a good optimization candidate.
In addition your proposal allows only single parameter functions calls which is in my eyes very restrictive.

[Rekkonnect]

In case you've not noticed already, this proposal aims to also get rid of the need to declare the name of the temporary variable, and it can only happen if you pass the method group as an argument for the ForEach.

The problem is this is immediately invalidated when more arguments get into the mix. Also, I'm more of a fan of having a language syntax support a simplification in itself without relying on custom functions.

[bernd5]

How would you write a function call with 2 arguments?
Like:

items.ForEach(i => Function(i.First, i.Second));

In addition I don't see what is wrong with this "i" - you can use any name - it has a very little scope.

What do you mean with:

The problem is this is immediately invalidated when more arguments get into the mix

[Rekkonnect]

How would you write a function call with 2 arguments?

This proposal doesn't aim to go that far, it's not intended to completely kill the classic foreach loop.

What do you mean with:

The problem is this is immediately invalidated when more arguments get into the mix

I mentioned that you could use the method group as the delegate argument for the ForEach function. What this means is doing items.ForEach(Function) instead of requiring to declare an extra variable. However, if Function takes more than one arguments, you resort to using the lambda expression, invalidating the solution of using the method group.

[CyrusNajmabadi]

I don't see the benefit here. All it seems to save is not writing the var keyword.

[En3Tho]

​foreach​ (​var​ ​c​ ​in​ ​chars​)
    ​stringBuilder​.​Append​(​c​).​Append​(​' '​);

​stringBuilder​.​Append​(​foreach​ ​in​ ​chars​).​Append​(​' '​);

First can't become second as there is a difference in logic. At least as I see it. First one adds a space for every iteration, second one doesn't. Seems like your new syntax could trick even yourself :) (or me)

[Rekkonnect]

It's correct because of the definition; the new syntax acts as a replacement of the temporary value with the expression foreach in enumerable.