Tail call foreach

[Thaina]

Sometime the Linq chain would be long and so ForEach extension method is neat in the code instead of create variable and run it at the end

But because it is delegate it was limited from some constraint unlike real foreach. So I would like to propose tail call foreach syntax

void DoSomethings(Item[] item,ref SomeStruct obj)
{
    collection.GroupBy((item) => {
        return item.GroupKey;
    }).OrderBy((items) => {
        return random.Next();
    }).SelectMany((items,index) => {
        return items.Select((item) => (item,index));
    }) foreach(var (item,index))
        DoSomething(item,index,ref obj); // can access ref
}

It would be transpiled to

void DoSomethings(Item[] item,ref SomeStruct obj)
{
    var __tmpCollection = collection.GroupBy((item) => {
        return item.GroupKey;
    }).OrderBy((items) => {
        return random.Next();
    }).SelectMany((items,index) => {
        return items.Select((item) => (item,index));
    });

    foreach(var (item,index) in __tmpCollection)
        DoSomething(item,index,ref obj); // can access ref
}

[marbergq]

Sorry, but I don't see the benefit. The select yields IEnumerabe. Doing foreach kind of defeats the lazy evaluation.
Though, on collections (which already have .ForEach ) extension, it makes sense, but then, the difference between that and this proposal isn't huge. Or did I miss something?

[Thaina]

@marbergq The difference is iterate collection without delegate is needed in some case as I mention about reference argument passed down in function

The benefit is not having unused variable whenever we want to only iterate at the place we have writing long chain linq

I mean when we write these kind of code anyway

void DoSomethings(Item[] item,ref SomeStruct obj)
{
    var tmpCollection = collection.GroupBy((item) => {
        return item.GroupKey;
    }).OrderBy((items) => {
        return random.Next();
    }).SelectMany((items,index) => {
        return items.Select((item) => (item,index));
    });

    foreach(var (item,index) in tmpCollection)
        DoSomething(item,index,ref obj); // can access ref
}

I just want it that we don't need to have variable tmpCollection. We don't really need it. And it avoid reuse that variable unintentionally

In my opinion a variable that would be used only one place should be get rid of it. Because other place should not have any knowledge about it. And long chain linq could make confusion about the name of variable we just make it just for cache. Chaining linq could be longer than screen

[MkazemAkhgary]

if you don't want to write temporary variable simply inline that variable. there is no need for new syntax.

Also Its a bit of joke where you are writing delegates instead of much shorter lambdas and trying to omit writing a temporary variable.

foreach(var (item, index) in collection.GroupBy(item => item.GroupKey).OrderBy(_ => random.Next()).SelectMany((items, index) => items.Select(item => (item, index)))
{
    DoSomething(item,index,ref obj);
}

By the way, your query seems to be unnecessarily complex. can you tell us what query you are trying to write? I'm pretty sure that can be simplified a lot, specially SelectMany and Select part.

[aluanhaddad]

@MkazemAkhgary those are lambdas.

@thania tail call is not the correct term for this. It refer to a technique for invoking recursive functions.

EDIT: @eyalsk kindly corrected me on this point. Tail call optimizations are not exclusive to recursive functions.

@marbergq foreach doesn't defeat laziness, it preserves it.

[Thaina]

@MkazemAkhgary If you take some time to listen you should see I was saying Chaining linq could be longer than screen I just write short example there but the real code might have complex logic for return object or filtering

FYI, What my example linq was doing is, grouping object with the same key into group, sort each group by random, and also sort the internal item of each group by random. And then flatten it

@aluanhaddad This is not feature for corefx What I propose here is syntax to transpiled into foreach not a ForEach method. But you may right, this may not be called tail call, But I don't know what this feature should be called

[aluanhaddad]

I'm sorry, I misunderstood. Isn't this effectively the same as the do query termination proposal if it's not an API then?

Maybe you would call this postfix methods.

[aluanhaddad]

@thania I also want to remark that your LINQ examples are frequently far less readable than they could be because you for some reason seem to object to the wonderful comprehension syntax that we have in C#.

I make this claim based on posts here and on the corefx repo. For example when you requested Cross because you found SelectMany to be ugly for creating a cartesian product.
Well as you know this is a solved problem in the language with dedicated syntactic support. Similarly, your code in the original post could be made much more readable by using the existing comprehension syntax

[Thaina]

@aluanhaddad I'm not sure what "from they could be" might be. Could you please enlighten me?

And I don't know what do proposal you mention about too

But anyway. My example linq is just a mock one. You could replace it with any better readable but having multiple line of chained linq. The point here is it normal when we write linq in multiple line and just want to foreach to do some work at the last. I don't like the way that we need one temp variable that will not be used anywhere except to foreach

[MkazemAkhgary]

Sorry, but I still fail to understand your problem.

I don't like the way that we need one temp variable that will not be used anywhere except to foreach

you are just contradicting your self. you say variable that will not be used anywhere, and you also say that its used by foreach.

You cant say a variable is not be used anywhere where you are actually using it.

No offense but you are being too obsessive. that's just a variable, omitting it doesn't massively change the way you read it or understand it.

[MkazemAkhgary]

and whether you inline that variable or write it down, both will be compiled into same thing. so its not like unnecessary temporary variable. a reference to that query must be stored somewhere in stack so it can be used by foreach. you cant avoid that. its needed.

[MkazemAkhgary]

(I know you may feel I'm not helping. so this is my last comment :) )

You can break your query like this if it becomes too big. this approach also compiles into exact same thing.

this may look better to you, it may not feel like unnecessary.

var query = collection.GroupBy(item => item.GroupKey);
query = query.OrderBy(items =>  random.Next());
query = query.SelectMany((items,index) => items.Select((item) => (item,index)));

foreach(var (item,index) in query)
    DoSomething(item,index,ref obj); // can access ref

[MattDillard]

Something like this has been proposed before in a few places, and seems to have a good amount of traction (or at least support):

#101 - Champion "Query-foreach (do query termination)"
#333 - [Proposal] extend language integrated query clauses with "apply" clause

Both of those are concerned with LINQ query syntax, not method syntax, but the desire is the same.

If you want something like that right now, without a language change, you can create an extension method:

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

You would then use it like this:

collection.GroupBy(item => item.GroupKey)
          .OrderBy(_ => Random.Next())
          .SelectMany((items, index) => items.Select(item => (item,index)))
          .ForEach((item, index) => DoSomething(item, index, ref obj));

[Thaina]

@MattDillard I had create that kind of extension method myself and actually it really common, many people do it

But the drawback is it not like the actual foreach keyword. As I already said it constraint by many limitation of being delegate. Such as what I point out that it cannot access ref argument of the function. While the real foreach can do it

But thanks for mention #101 now I know what do proposal @aluanhaddad means

[Thaina]

@MkazemAkhgary You don't understand the whole point of me that I don't want to have variable in scope and mutate it for chaining

At least I think most people would just write it like this

var query = collection.GroupBy(item => item.GroupKey)
                    .OrderBy(items =>  random.Next())
                    .SelectMany((items,index) => items)
                    .Select((item) => (item,index)));

So that the query variable would be assigned only once, we could make it readonly if there are readonly local support. The point here is the variable would not be mutate after assigned is better

I just don't like dot in the start line so I make it as a block instead. But it just the same code. The main issue here is I propose that the query variable itself could also be dismissed too by having foreach or do syntax aware about the whole linq before it

I think most people here understand me or at least understand about proposal #101, or at the very least there are many people who make extension method name ForEach or Execute or Do for iterate long linq code at the end of chain

As for this proposal I just try to pose a problem that this feature should not be extension method. But the reason for having postfix foreach is the same for anyone writing ForEach function

[aluanhaddad]

@thania sorry for not citing my source. This is the issue that you opened: dotnet/corefx/issues/23005 and the subsequent comment on that issue that I specifically take issue with: https://github.com/dotnet/corefx/issues/23005#issuecomment-340417952

For what it's worth, I personally would like to see #101 in some form, but I don't understand why you would be requesting syntactic sugar when you reject existing syntactic sugar, despite how sweet it is.

[Thaina]

@aluanhaddad I don't like the linq syntax that syntactic sugar for extension method because it add more keyword to the language while not really do anything better. I like syntactic sugar but linq is not, it's salt. Linq extension method is far more powerful. We could mix and match custom extension method along with linq in the same pattern and style. Linq syntax is nonsense and linq extension method is really far more better in my opinion

In this issue I don't add new keyword and also I need to overcome limitation of delegate. I would not need this feature I propose here if we have alternative way to make direct iteration without creating delegate, or making delegate can access ref argument. Which I was trying to propose in many issue such as local anonymous function

I don't know how #101 would be transpile to. But if it not transpile to direct foreach then it would still could not access ref argument. Which is not what I want. But if it could I would support that issue

[aluanhaddad]

Since #101 is a proposal to extend LINQ I would be extremely surprised if it did not transform into delegate invocations.

As for LINQ syntax being nonsense, it isn't anything of the sort. Everything from its ordering of clauses, scoping of identifiers, inherent toolability, and "patterns over methods" approach that generalizes it to user-defined-types is very well thought-out and very elegant.

I would say that you and I have different tastes, but given that you claimed it's nonsense, I'll go so far as to say that you have bad taste.

[Thaina]

@aluanhaddad

var filter = from collection select item where item.Yes;
var filter = collection.Select((item) => item).Where((item) => item.Yes);

Just try to save only some keystroke while it disguise as pattern. It a bad taste that it not an actually code in the same stack like it seem, which cause many inconvenient confusion

Also by the sentence patterns over methods sound good. But how about adding our own patterns?

While method might look less neat. It easy to extend and have less learning curve because it is the same as other method with callback function. It more universal and powerful. So trying to hide by having linq syntax over it is nonsense

[aluanhaddad]

@thania since the example code in your snippet is not valid C#, I conclude that you do not understand the LINQ syntax. Don't dismiss what you don't understand. Certainly don't attack it.

Your remarks also imply that you never use comprehensions in Python, Haskell, F#, Scala, or any other language that has them.

Learning is good for you.

[Thaina]

@aluanhaddad It not related to any other language. Pattern like this might be doing well in any other language. But in C family like C# it not intuitive at all

I have learn LINQ syntax since long long time ago and consider that it not familiar for me unlike linq method so I just forgot it that's why I don't remember it perfectly

[aluanhaddad]

The same argument could have been made and was made by C programmers when C++ was introduced. Classes came from Simula.

[Thaina]

@aluanhaddad Still C++ class has the similar syntax as C struct

[aluanhaddad]

Except that they don't have the same semantics. In fact, C++ structs don't have the same semantics as C structs. C# has evolved very fiercely and I don't find your argument for rejecting a feature that has been there for 5 versions compelling.

[Thaina]

@aluanhaddad Having feature since any version does not mean everyone would use it. We also have volatile and stackalloc that rarely be used

[DavidArno]

@Thaina,

I don't like the linq syntax that syntactic sugar for extension method because it add more keyword to the language while not really do anything better. I like syntactic sugar but linq is not, it's salt.

For what it's worth, I completely disagree. I love the linq query syntax and use it near-daily. It's one of the best bits of sugar added to the language in my view.

Each to their own, I guess.

[aluanhaddad]

Yes but query expressions are very commonly used and were very well received.

Here's a different example: closures.

I believe you would agree that they are both essential and idiomatic, but they would be very foreign to someone coming from a language that doesn't have them.