async & await - опрос альтернатив [закрыт]

Теперь, когда мы знаем, что ожидает c # 5, нам, видимо, еще есть возможность повлиять на выбор двух новых ключевых слов для « асинхронности », которые были анонсированы Андерсом Хейсбергом вчера на 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);
    }
}

У Эрика Липперта есть объяснение выбора двух текущих ключевых слов и того, как их неправильно поняли в исследованиях юзабилити. В комментариях есть несколько других предложений.

Пожалуйста - одно предложение за ответ, дубликаты будут уничтожены.

Учитывая, что я не совсем понимаю значение / необходимость async, я не могу спорить с этим, но мое лучшее предложение для замены await:

yield while (смотрите! нет новых ключевых слов)

Обратите внимание , подумав об этом немного больше, я задаюсь вопросом, является ли повторное использование whileтаким способом хорошей идеей - естественной тенденцией будет ожидание логического значения после этого.

(Думает: поиск хороших ключевых слов - это как поиск хороших доменных имен :)

Как насчет отсутствия ключевого слова?

Я бы хотел, чтобы компилятор понял, что большую часть времени, когда я вызываю асинхронный метод, я хочу получить его результат.

Document doc = DownloadDocumentAsync();

Вот и все. Причина, по которой людям трудно придумать ключевое слово для этой вещи, заключается в том, что это все равно, что иметь ключевое слово для «делай то, что сделал бы, если бы все было совершенно нормально». Это должно быть по умолчанию, а не требовать ключевое слово.

Обновить

Первоначально я предложил компилятору разобраться с выводом типа, чтобы понять, что делать. Подумав об этом дальше, я бы сохранил существующую реализацию в CTP как есть, но сделаю пару тривиальных дополнений к ней, чтобы уменьшить случаи, когда вам нужно будет использоватьawait явно ключевое слово.

Мы изобретаем атрибут: [AutoAwait]. Это может быть применено только к методам. Один из способов применить это к вашему методу - пометить его async. Но вы также можете сделать это вручную, например:

[AutoAwait]
public Task<Document> DownloadDocumentAsync()

Затем внутри любого asyncметода компилятор будет предполагать, что вы хотите ожидать вызова DownloadDocumentAsync, поэтому вам не нужно его указывать. Любой вызов этого метода будет автоматически ожидать его.

Document doc = DownloadDocumentAsync();

Теперь, если вы хотите «стать умным» и получить Task<Document>, вы используете оператор start, который может появиться только перед вызовом метода:

Task<Document> task = start DownloadDocumentAsync();

Я думаю, аккуратно. Теперь простой вызов метода означает то, что он обычно означает: дождитесь завершения метода. И startуказывает на что-то другое: не ждите.

Для кода, который появляется за пределами asyncметода, единственный способ, которым вы можете вызывать [AutoAwait]метод - это префикс его start. Это заставляет вас писать код, имеющий одинаковое значение, независимо от того, появляется он в asyncметоде или нет.

Тогда я начинаю жадничать! :)

Во-первых, я хочу asyncприменить методы интерфейса:

interface IThing
{
    async int GetCount();
} 

В основном это означает, что метод реализации должен возвращать Task<int>или что-то совместимое с await, и вызывающие методы получат [AutoAwait]поведение.

Также, когда я реализую описанный выше метод, я хочу иметь возможность написать:

async int GetCount()

Так что я не должен упоминать Task<int>в качестве типа возврата.

Кроме того, я хочу asyncприменить к типам делегатов (которые, в конце концов, похожи на интерфейсы с одним методом). Так:

public async delegate TResult AsyncFunc<TResult>();

asyncДелегат имеет - вы уже догадались - [AutoAwait]поведение. Из asyncметода вы можете вызывать его, и он будет автоматически awaitредактироваться (если вы не решите просто startего). И так, если вы скажете:

AsyncFunc<Document> getDoc = DownloadDocumentAsync;

Это просто работает. Это не вызов метода. Ни одна задача еще не была запущена - это async delegateне задача. Это фабрика для постановки задач. Ты можешь сказать:

Document doc = getDoc();

И это запустит задачу и будет ждать ее завершения и даст вам результат. Или вы можете сказать:

Task<Document> t = start getDoc();

Таким образом, единственное место в этом, где просачивается «сантехника», это то, что если вы хотите создать делегат для asyncметода, вы должны знать, чтобы использовать async delegateтип. Так что вместо Funcтебя надо сказать AsyncFuncи так далее. Хотя однажды такие вещи можно исправить с помощью улучшенного вывода типа.

Другой вопрос, что должно произойти, если вы скажете начать с обычного (не асинхронного) метода. Очевидно, что ошибка компиляции будет безопасным вариантом. Но есть и другие возможности.

hearken unto AsyncFetch(…)

(если вы не получите его, прочитайте запись Эрика в блоге . По крайней мере, это лучше, чем for sooth Romeo wherefore art thou AsyncFetch(…))

Я думаю, что asyncэто хорошо, но, возможно, это потому, что я связываю это с асинхронными страницами ASP.NET - та же идея.

Для awaitключевого слова я предпочитаю continue afterили resume after.

Мне не нравится yieldни один из его вариантов, потому что семантика такова, что метод может никогда не привести к выполнению; это зависит от состояния задачи.

Я добавил к комментариям в блоге Эрика тоже, я не вижу проблем с использованием того же ключевого слова async

var data = async DownloadFileAsync(url);

Я просто заявляю, что хочу загрузить файл асинхронно. Здесь есть небольшая избыточность, «асинхронность» появляется дважды, потому что она тоже есть в имени метода. Компилятор может быть очень умным и обнаружить соглашение о том, что методы, оканчивающиеся на «Async», являются фактически асинхронными методами, и добавить это для нас в скомпилированном коде. Так что вместо этого вы можете просто позвонить

var data = async DownloadFile(url);

в отличие от вызова синхронного

var data = DownloadFile(url);

Черт возьми, мы также должны иметь возможность определять их одинаково, поскольку в нашем объявлении есть ключевое слово async, почему мы должны вручную добавлять «Async» к каждому имени метода - компилятор может сделать это за нас.

async = task - это изменение функции для возврата задачи, так почему бы не использовать ключевое слово "task"?

await = finish - нам не обязательно ждать, но задача должна "закончиться", прежде чем использовать результат.

Мне нравится yield until. yield whileКак уже говорилось, это здорово, и не вводит никаких новых ключевых слов, но я думаю, что «пока» не поймет поведение немного лучше.

Я думаю, что yield <something>это отличная идея, потому что yield уже отражает идею превращения оставшейся части метода в продолжение. Может быть, кто-то может придумать лучшее слово, чем «до».

Я просто хочу зарегистрировать свой голос за предложение Аарона Дж comefrom- первое соответствующее использование заявления COMEFROM от INTERCAL . Идея состоит в том, что это своего рода противоположность GOTO (отходит от оператора GOTO) в том, что в вашем коде происходит переход к команде COMEFROM.

Поскольку мы имеем дело с Task<T>s, как насчет использования startв качестве ключевого слова перед оператором, как в:

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

Стоит отметить, что F # также использует asyncключевое слово в своих асинхронных рабочих процессах, что в значительной степени совпадает с новой функциональностью асинхронности в C # 5. Поэтому я бы сохранил это

Для awaitключевого слова в F # они просто используют let!вместо let. C # не имеет такой же синтаксис присваивания, поэтому им нужно что-то справа от =знака. Как сказал Бенджол, он функционирует так же, как yieldи должен быть почти таким вариантом.

yield async FetchAsync(..)

Это прекрасно сочетается с asyncмодификатором, который вам нужен для метода, который вы вызываете. А также семантика текущего, yield returnто есть вы возвращаете выполнение и передаете его перечисляющему коду, в этом случае вы уступаете свое выполнение асинхронному методу.

Представьте, что в будущем появятся другие варианты использования yield, мы могли бы добавить, yield xгде x - это блестящая новая функция вместо того, чтобы все эти разные ключевые слова выполняли в основном одно и то же, принося результат.

Честно говоря, я не совсем понимаю аргумент «не поддающийся казни». В конце концов, разве смысл в том, чтобы вызывать другой метод, уже заключается в том, чтобы «дать выполнение» этому методу? Независимо от того, является ли он асинхронным или нет? Я что-то здесь упускаю?

И хорошо, если asyncвозврат выполняется синхронно, но наличие ключевого слова должно означать, что есть вероятность того, что метод будет работать асинхронно и что вы уступите выполнение другому методу. Ваш метод должен учитывать это независимо от того, выполняет ли метод асинхронные вызовы или нет.

ИМО Я думаю, что различные «не приносящие» случаи являются деталями реализации. Я предпочел бы ручаться за последовательность в языке (то есть повторное использование yield).

Как насчет того complete, как в «Я хочу, чтобы задача была выполнена»?

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

task(для объявления метода) и async(в теле метода)