[proposal] Could the Paralle.For/ Foreach become key words.

[TruePluto]

Could use the parallelfor parallelforeach as key words such as for foreach to do circile parallelly.
Current the function style is so ugly.

for (int i =0; i <10; i++)
dosomething(i);

int
Parallel.For(0,10,
(i)=>dosomething(i));

change to

parallelfor( int i =0; i <10; i++)
dosomething(i);
and its easy to change to single threat and debug.

[svick]

and its easy to change to single threat and debug.

Another way to do that is to use ParallelOptions with MaxDegreeOfParallelism set to 1. I.e. change:

Parallel.For(0, 10, (i)=>dosomething(i));

to:

Parallel.For(0, 10, new ParallelOptions { MaxDegreeOfParallelism = 1 }, (i)=>dosomething(i));

---

More importantly:

• for is inherently non-parallel, at least in the way its iteration is controlled (increment, ending condition, break). For example, this is a valid way to iterate a LinkedList<T>:

  for (var node = linkedList.First; node != null; node = node.Next)
  {
      Console.WriteLine(node.Value);
  }

  But what would the following source compile to?

  parallelfor (var node = linkedList.First; node != null; node = node.Next)
  {
      Console.WriteLine(node.Value);
  }

  I'm pretty sure you couldn't use any of the existing overloads of Parallel.For for this.

• Parallel.For and Parallel.ForEach have knobs to tune how they behave, like the above mentioned MaxDegreeOfParallelism. I think those knobs are pretty important, how would the proposed syntax account for them?

[scalablecory]

I don't see enough bang-for-buck here. The typing and performance savings of a keyword over calling Parallel.For are minimal or non-existent.

[HaloFour]

I'm with @svick on this one.

There is no other construct in C# that allows for "forking" execution in the middle of a method. Having multiple threads automatically start executing within the loop body would be unexpected. With lambdas/delegates there is an expected separation as to if/when/how the delegate will be invoked.

Constructs like Parallel.For often have various overloads or options to control the policy of execution. It would be awkward to try to incorporate that into the language as well would limit the potential to add more options going forward without requiring corresponding language modifications. As mentioned it's already possible to dial-down the degree of parallelization in those cases where you're trying to debug.

Then there's the argument that if it can be managed easily enough with a library method that there's really no need for a language modification anyway. The syntax for Parallel.For is not much more verbose than a normal loop would be.