Dziwny błąd składni

Krótko chodzi o to, że zarówno VS2008, jak i VS2010 nie przyjmują takiej konstrukcji składniowej:

new [] {1, 2, 3}.ForEach(
    n => throw new Exception() );

Taka składnia jest poprawna:

new [] {1, 2, 3}.ForEach(
    n => new Exception() );
new[] { 1, 2, 3 }.ForEach(
    n => { throw new Exception() } );

Szybkośc działania .NET 4.0 Beta

Ciężko jest przeprowadzić dokładne testy. Sprawdzone zostaną dwa moje programy: jeden instesywnie liczący program do renderingu, drugi intensywnie wykorzystujący LINQ to objects solver do sudoku i metoda Math.Round(). Math.Round() jest jakieś dwa razy szybsze.

public void Test()
{
   System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
   sw.Start();
   for (int i = 0; i < 10000; i++)
   {
       for (int j = 0; j < 1000; j++)
       {
           int xx = (int)Math.Round(i * j / 39.4);
       }
   }
   sw.Stop();
   System.Console.WriteLine("Math.Round(): {0}", sw.ElapsedMilliseconds);
}

To była pierwsza rzecz jaką sprawdziłem. Zapamiętałem ją, bo profilując jedną aplikację okazało się, że idzie na to stosunkowo dużo czasu. A jak się przyjrzałem natywnym debugerem (WinDbg) co się tam dzieje w tej metodzie, to wiedziałem jedno, że jak zależy nam na prędkości to lepiej napisać swoją własną wersję. Jak widać było co tam przyspieszać. Drugi test dotyczył szybkości działania LINQ to objects. Niestety źródeł aplikacji tutaj nie mogę podać. Jest to aplikacja rozwiązująca Sudoku przy pomocy właśnie LINQ. Można powiedzieć, że LINQ jest tak samo szybkie (a raczej wolne) jak było. No i test trzeci, moja własna aplikacja do raytracingu. Tutaj także nie ma się co rozpisywać, prędkość renderowania przykładowej sceny nie zmieniła się. Czyli można powiedzieć, że za wyjątkiem pojedyńczych funkcji, które ewidentnie były wolne, ogólnego przyspieszenia nie należy się spodziewać. Cały proces konwersji solucji i projektów do VS2010, jak i kompilacji przebiegał bezproblemowo.