W C#, dlaczego anonimowa metoda nie może zawierać instrukcji yield?

Eric Lippert napisał znakomitą serię artykułów na temat ograniczeń (i decyzji projektowych wpływających na te wybory) na blokach iteratora

W szczególności bloki iteratora są implementowane przez niektóre zaawansowane transformacje kodu kompilatora. Transformacje te oddziaływałyby na transformacje, które zachodzą wewnątrz funkcji anonimowych lub lambda, tak że w pewnych okolicznościach obie próbowałyby "przekształcić" kod w inną konstrukcję, która była niezgodna z innymi.

Jak działają bloki iteratora pod maską, dobrze sobie radzimy tutaj.

Jako prosty przykład niezgodności:

public IList<T> GreaterThan<T>(T t)
{
    IList<T> list = GetList<T>();
    var items = () => {
        foreach (var item in list)
            if (fun.Invoke(item))
                yield return item; // This is not allowed by C#
    }

    return items.ToList();
}

Kompilator chce jednocześnie przekonwertować to na coś w stylu:

// inner class
private class Magic
{
    private T t;
    private IList<T> list;
    private Magic(List<T> list, T t) { this.list = list; this.t = t;}

    public IEnumerable<T> DoIt()
    {
        var items = () => {
            foreach (var item in list)
                if (fun.Invoke(item))
                    yield return item;
        }
    }
}

public IList<T> GreaterThan<T>(T t)
{
    var magic = new Magic(GetList<T>(), t)
    var items = magic.DoIt();
    return items.ToList();
}

I jednocześnie aspekt iteracyjny próbuje wykonać swoją pracę, aby stworzyć małą maszynę stanową. Niektóre proste przykłady mogą działać z dużą ilością sprawdzanie sanity (najpierw zajmowanie się (ewentualnie arbitralnie) zagnieżdżonymi zamknięciami), a następnie sprawdzanie, czy wynikowe klasy dolnego poziomu mogą zostać przekształcone w maszyny stanu iteratora.

Jakkolwiek by to było

Sporo pracy.
1. nie mógłby działać we wszystkich przypadkach, gdyby chociaż aspekt bloku iteratora nie był w stanie uniemożliwić aspektowi zamknięcia stosowania pewnych przekształceń dla wydajności (jak promowanie zmiennych lokalnych do instancji zmienne zamiast pełnowartościowej klasy zamknięcia).
   • gdyby istniała nawet niewielka szansa na nakładanie się tam, gdzie niemożliwe lub wystarczająco trudne, aby nie zostać wdrożonym, wówczas liczba problemów związanych z obsługą byłaby prawdopodobnie wysoka, ponieważ subtelna zmiana łamiąca zostałaby utracona przez wielu użytkowników.
2. można go bardzo łatwo obejść.

W twoim przykładzie tak:

public IList<T> Find<T>(Expression<Func<T, bool>> expression) 
    where T : class, new()
{
    return FindInner(expression).ToList();
}

private IEnumerable<T> FindInner<T>(Expression<Func<T, bool>> expression) 
    where T : class, new()
{
    IList<T> list = GetList<T>();
    var fun = expression.Compile();
    foreach (var item in list)
        if (fun.Invoke(item))
            yield return item;
}

Niestety Nie wiem, dlaczego na to nie pozwolili, ponieważ oczywiście jest całkowicie możliwe, aby wyobrazić sobie, jak to będzie działać.

Jednak metody anonimowe są już częścią "magii kompilatora" w tym sensie, że metoda zostanie wyodrębniona albo do metody w istniejącej klasie, albo nawet do zupełnie nowej klasy, w zależności od tego, czy dotyczy zmiennych lokalnych, czy nie.

Dodatkowo zaimplementowane są również metody iteracyjne wykorzystujące yield przy użyciu kompilatora Magia.

Domyślam się, że jeden z tych dwóch elementów sprawia, że kod nie jest identyfikowalny z drugim kawałkiem magii, i że zdecydowano się nie poświęcać czasu na to, aby to działało dla obecnych wersji kompilatora C#. Oczywiście może to wcale nie być świadomy wybór i że po prostu nie działa, ponieważ nikt nie pomyślał, aby go wdrożyć.

Na 100% trafne pytanie proponuję skorzystać ze strony Microsoft Connect i zgłosić pytanie, jestem pewien, że coś dostaniesz użyteczny w zamian.

Zrobiłbym to:

IList<T> list = GetList<T>();
var fun = expression.Compile();

return list.Where(item => fun.Invoke(item)).ToList();

using System.Linq;

Sly

Może to tylko ograniczenie składni. W Visual Basic. NET, który jest bardzo podobny do C#, jest to całkowicie możliwe, podczas gdy niewygodne napisać

Sub Main()
    Console.Write("x: ")
    Dim x = CInt(Console.ReadLine())
    For Each elem In Iterator Function()
                         Dim i = x
                         Do
                             Yield i
                             i += 1
                             x -= 1
                         Loop Until i = x + 20
                     End Function()
        Console.WriteLine($"{elem} to {x}")
    Next
    Console.ReadKey()
End Sub

Zwróć również uwagę na nawiasy ' here; funkcję lambda Iterator Function...End Function zwraca an IEnumerable(Of Integer) ale nie jest takim obiektem. Trzeba go wezwać, aby zdobyć ten przedmiot.

Skonwertowany Kod przez [1] powoduje błędy w C # 7.3 (CS0149):

static void Main()
{
    Console.Write("x: ");
    var x = System.Convert.ToInt32(Console.ReadLine());
    // ERROR: CS0149 - Method name expected 
    foreach (var elem in () =>
    {
        var i = x;
        do
        {
            yield return i;
            i += 1;
            x -= 1;
        }
        while (!i == x + 20);
    }())
        Console.WriteLine($"{elem} to {x}");
    Console.ReadKey();
}

Zdecydowanie nie zgadzam się z uzasadnieniem podanym w innych odpowiedziach, że jest to trudne dla kompilatora do obsługi. Iterator Function() widzisz w VB.NET example jest stworzony specjalnie dla iteratorów lambda.

W VB Znajduje się słowo kluczowe Iterator; nie ma ono odpowiednika w języku C#. IMHO, nie ma prawdziwego powodu, dla którego nie jest to cecha C#.

Więc jeśli naprawdę, naprawdę chcesz anonimowych funkcji iteratora, obecnie używaj Visual Basic lub (nie sprawdzałem tego) F#, jak stwierdzono w komentarzu Część # 7 w odpowiedzi @Thomas Levesque (wykonaj Ctrl+F dla F#).