async i czekaj - ankieta w sprawie alternatyw [zamknięte]

Teraz, gdy wiemy, co czeka nas na c # 5, najwyraźniej nadal mamy możliwość wpływania na wybór dwóch nowych słów kluczowych dla „ Asynchronii ”, ogłoszonych wczoraj przez Andersa Heijsberga na PDC10 .

async void ArchiveDocuments(List<Url> urls) {
    Task archive = null;
    for(int i = 0; i < urls.Count; ++i) {
        var document = await FetchAsync(urls[i]);
        if (archive != null)
            await archive;
        archive = ArchiveAsync(document);
    }
}

Eric Lippert wyjaśnił wybór dwóch aktualnych słów kluczowych oraz sposób, w jaki zostały one źle zrozumiane w badaniach użyteczności. Komentarze mają kilka innych propozycji.

Proszę - jedna sugestia na odpowiedź, duplikaty zostaną zniszczone.

Biorąc pod uwagę, że nie jestem pewien co do znaczenia / konieczności async, tak naprawdę nie mogę się z tym kłócić, ale moja najlepsza propozycja zastąpienia awaitto:

yield while (patrz! brak nowych słów kluczowych)

Zauważmy, że zastanowiwszy się nad tym trochę, zastanawiam się, czy ponowne użycie whilew ten sposób jest dobrym pomysłem - naturalną tendencją byłoby oczekiwanie później wartości logicznej.

(Myśli: znalezienie dobrych słów kluczowych jest jak znalezienie dobrych nazw domen :)

Co powiesz na brak słowa kluczowego?

Chciałbym, aby kompilator zdał sobie sprawę, że przez większość czasu, gdy wywołuję metodę asynchroniczną, chcę jej wynik.

Document doc = DownloadDocumentAsync();

Otóż ​​to. Powodem, dla którego ludzie mają trudności z wymyśleniem słowa kluczowego dla tej rzeczy, jest to, że jest to słowo kluczowe dla „rób to, co zrobiłbyś, gdyby wszystko było całkowicie normalne”. To powinno być domyślne, nie wymagać słowa kluczowego.

Aktualizacja

Początkowo zasugerowałem, że kompilator powinien być sprytny z wnioskami o typ, aby dowiedzieć się, co robić. Zastanawiając się nad tym, chciałbym zachować obecną implementację w CTP w obecnej postaci, ale dodam do niej kilka trywialnych dodatków, aby zmniejszyć liczbę przypadków, w których konieczne byłoby awaitjawne użycie słowa kluczowego.

Wymyślamy atrybut: [AutoAwait]. Można to zastosować tylko do metod. Jednym ze sposobów, aby zastosować to do metody, jest jej oznaczenie async. Ale możesz to również zrobić ręcznie, np .:

[AutoAwait]
public Task<Document> DownloadDocumentAsync()

Następnie w każdej asyncmetodzie kompilator zakłada, że ​​chcesz poczekać na wywołanie DownloadDocumentAsync, więc nie musisz go określać. Każde wywołanie tej metody będzie automatycznie na nią czekało.

Document doc = DownloadDocumentAsync();

Teraz, jeśli chcesz „uzyskać spryt” i uzyskać Task<Document>, użyj operatora start, który może pojawić się tylko przed wywołaniem metody:

Task<Document> task = start DownloadDocumentAsync();

Zgrabnie, tak myślę. Teraz zwykłe wywołanie metody oznacza to, co zwykle oznacza: poczekaj na zakończenie metody. I startwskazuje coś innego: nie czekaj.

W przypadku kodu, który pojawia się poza asyncmetodą, jedynym sposobem na wywołanie [AutoAwait]metody jest przedrostek start. Zmusza to do pisania kodu o tym samym znaczeniu, niezależnie od tego, czy pojawia się w asyncmetodzie, czy nie.

Potem zaczynam być chciwy! :)

Po pierwsze, chcę asynczastosować się do metod interfejsu:

interface IThing
{
    async int GetCount();
} 

Zasadniczo oznacza to, że metoda implementująca musi zwrócić Task<int>lub coś kompatybilnego await, a osoby wywołujące metodę otrzymają [AutoAwait]zachowanie.

Również po wdrożeniu powyższej metody chcę móc pisać:

async int GetCount()

Więc nie muszę wspominać Task<int>o typie zwrotu.

Chcę asyncrównież zastosować do typów delegowanych (które przecież są jak interfejsy z jedną metodą). Więc:

public async delegate TResult AsyncFunc<TResult>();

asyncDelegat posiada - zgadliście - [AutoAwait]zachowanie. Z asyncmetody możesz ją wywołać, a zostanie ona automatycznie awaitedytowana (chyba że zdecydujesz się to startzrobić). A więc jeśli powiesz:

AsyncFunc<Document> getDoc = DownloadDocumentAsync;

To po prostu działa. To nie jest wywołanie metody. Żadne zadanie nie zostało jeszcze uruchomione - async delegatenie jest zadaniem. To fabryka do wykonywania zadań. Możesz powiedzieć:

Document doc = getDoc();

A to rozpocznie zadanie i zaczekaj, aż się zakończy i da ci wynik. Lub możesz powiedzieć:

Task<Document> t = start getDoc();

Tak więc jednym z miejsc, w których przecieka „hydraulika”, jest to, że jeśli chcesz delegować asyncmetodę, musisz wiedzieć, że używasz async delegatetypu. Zamiast tego Funcmusisz powiedzieć AsyncFunci tak dalej. Chociaż pewnego dnia tego rodzaju rzeczy mogą zostać naprawione przez lepsze wnioskowanie o typie.

Innym pytaniem jest, co powinno się stać, jeśli powiesz, że zacznij od zwykłej metody (nie asynchronicznej). Oczywiście błąd kompilacji byłby bezpieczną opcją. Ale są też inne możliwości.

hearken unto AsyncFetch(…)

(jeśli go nie dostaniesz, przeczytaj wpis na blogu Erica . Przynajmniej jest lepszy niż for sooth Romeo wherefore art thou AsyncFetch(…))

Myślę, że asyncjest w porządku, ale może dlatego, że kojarzę go ze stronami asynchronicznymi ASP.NET - ten sam pomysł.

Dla awaitsłowa kluczowego wolę continue afterlub resume after.

I nie jak yieldlub któregokolwiek z jej wariantów, ponieważ semantyka są takie, że metoda nie może faktycznie uzyskując wykonanie; zależy to od stanu zadania.

Dodałem też do komentarzy na blogu Erica, nie widzę problemów z używaniem tego samego słowa kluczowego async

var data = async DownloadFileAsync(url);

Wyrażam tylko, że chcę asynchronicznie pobrać plik. Jest tu trochę redundancji, „asynchronizacja” pojawia się dwa razy, ponieważ jest również w nazwie metody. Kompilator może być wyjątkowo sprytny i wykryć konwencję, że metody kończące się na „Async” są w rzeczywistości metodami asynchronicznymi, i dodać to dla nas w skompilowanym kodzie. Zamiast tego możesz po prostu zadzwonić

var data = async DownloadFile(url);

w przeciwieństwie do wywoływania synchronicznego

var data = DownloadFile(url);

Heck, powinniśmy być w stanie zdefiniować je w ten sam sposób, ponieważ słowo kluczowe async znajduje się w naszej deklaracji, dlaczego musimy ręcznie dodać „Async” do nazwy każdej metody - kompilator może to zrobić za nas.

async = zadanie - modyfikuje funkcję, aby zwrócić zadanie, więc dlaczego nie użyć słowa kluczowego „zadanie”?

czekaj = zakończ - niekoniecznie musimy czekać, ale zadanie musi „zakończyć” przed użyciem wyniku.

Lubię yield until. yield while, już zasugerowany, jest świetny i nie wprowadza żadnych nowych słów kluczowych, ale myślę, że „dopóki” nie uchwyci zachowania nieco lepiej.

Uważam, że yield <something>to świetny pomysł, ponieważ wydajność już uchwyciła ideę uczynienia reszty metody tak dobrą kontynuacją. Może ktoś wymyśli lepsze słowo niż „do”.

Chcę tylko zarejestrować swój głos na sugestię Aarona G. comefrom- pierwsze właściwe zastosowanie, jakie widziałem w oświadczeniu INTERCAL COMEFROM . Chodzi o to, że jest to przeciwieństwo GOTO ( odskakiwanie od instrukcji GOTO), ponieważ powoduje, że pewne miejsce w kodzie przeskakuje do instrukcji COMEFROM.

Skoro mamy do czynienia z Task<T>s, to jak użyć startsłowa kluczowego poprzedzającego instrukcję, jak w:

start var document = FetchAsync(urls[i]);

Warto zauważyć, że F # używa również asyncsłowa kluczowego w swoich obiegach pracy asynchronicznej, co jest właściwie dokładnie tym samym, co nowa funkcja asynchroniczna w C # 5. Dlatego nie zmieniłbym tego

W przypadku awaitsłowa kluczowego w języku F # używają po prostu let!zamiast let. C # nie ma tej samej składni przypisania, więc potrzebują czegoś po prawej stronie =znaku. Jak powiedział Benjol, działa tak samo, yieldwięc powinien być niemal wariantem tego.

yield async FetchAsync(..)

To doskonale pasuje do asyncmodyfikatora, który musisz zastosować do metody, którą wywołujesz. A także semantyczny prądu yield return, to znaczy, że zwracasz i dajesz wykonanie kodowi wyliczającemu, podczas gdy w tym przypadku dajesz swoje wykonanie metodzie asynchronicznej.

Wyobraź sobie, że w przyszłości będą inne zastosowania yield, moglibyśmy dodać yield xgdzie x jest lśniącą nową funkcją zamiast posiadania tych wszystkich różnych słów kluczowych do robienia głównie tego samego, czyli wykonywania wydajności.

Szczerze mówiąc, nie do końca rozumiem argument „nie poddawanie się”. W końcu, czy nie ma sensu wywoływać innej metody w celu „wykonania” tej metody? Niezależnie od tego, czy jest asynchroniczny czy nie? Coś tu brakuje?

I dobrze, jeśli asynczwroty są synchroniczne, ale słowo kluczowe powinno oznaczać, że istnieje prawdopodobieństwo, że metoda będzie działać asynchronicznie i że wykonasz wykonanie innej metody. Twoja metoda powinna to uwzględnić niezależnie od tego, czy metoda faktycznie wykonuje wywołania asynchroniczne, czy nie.

IMO Myślę, że różne przypadki „niepoddawania się” są szczegółami wdrożenia. Wolę ręczyć za spójność w języku (tj. Ponowne użycie yield).

A może completejak w „Chcę, aby zadanie zostało wykonane”?

Task<byte[]> downloadTask = DownloadFileAsync(url);
byte[] data = complete downloadTask;

task(w przypadku deklaracji metody) i async(w treści metody)