Parallel ForEach Proposal about go-linq

[kalaninja]

it is a good example, though I think that adding extra logic to the method will make it not so lightweight as we try to keep it. I suggest to implement this logic in plinq api, which is probable to happen sometime in the future.

[ahmetb]

@kalaninja Agreed. Normally, we could have ForEach and ForEachAsParallel, but I bet most people will get the job done with a simple go f() inside ForEach + sync.WaitGroup

Personally, if I have a slice of 100,000 items, I don‘t want ForEach to create a goroutine for each of them in the background (this is an easy way to run out of file descriptors on linux and crash your program).

I feel most Go programmers want to have finer control over their concurrency code. For instance instead of running 100,000 goroutines concurrently, I can develop a system that would control max concurrent jobs etc. I think I'd like to see a simpler design which we can incorporate, before tagging v3.0.

As per the design I think I am fine with @kalaninja's original design which was:

• func (Query) ForEach(func(v interface{})
• func (Query) ForEachIndexed(i int, func(v interface{})
• ForEachT, ForEachIndexedT

Thoughts?

[ahmetb]

Closing this as #57 is merged.

@kalaninja If your commit message (not the title) or the PR descriptionincludes Closes #58, such issues will be automatically closed. More info:

https://help.github.com/articles/closing-issues-via-commit-messages/
https://github.com/blog/1506-closing-issues-via-pull-requests

[kalaninja]

thanks @ahmetalpbalkan. I always forget about this feature when commiting changes