Почему не все функции должны быть асинхронными по умолчанию?

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

если весь мой код медленно превращается в асинхронный, почему бы просто не сделать все это асинхронным по умолчанию?

Ну, ты преувеличиваешь; все ваш код не асинхронный. Когда вы добавляете два "простых" целых числа вместе, вы не ждете результата. Когда вы добавляете два будущие целые числа вместе, чтобы получить третий будущее целого числа -- потому что Task<int> это целое число, к которому вы получите доступ в будущем-конечно, вы, вероятно, будете ждать результата.

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

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

в теории теория и практика одинаковы. На практике они никогда являются.

позвольте мне дать вам три очка против такого рода трансформации с последующим оптимизация.

первый пункт снова: асинхронность в C#/VB / F# по существу является ограниченной формой продолжение прохождения. Огромное количество исследований в функциональном языковом сообществе ушло на выяснение способов определения того, как оптимизировать код, который интенсивно использует стиль передачи продолжения. Команда компилятора, вероятно, придется решать очень похожие проблемы в мире, где "асинхронный" был по умолчанию и не-async-методов должны быть выявлены и де-асинхронный-маньяков. Команда C# на самом деле не заинтересована в решении открытых исследовательских проблем, так что это большие очки против прямо там.

второй момент заключается в том, что C# не имеет уровня "ссылочной прозрачности", который делает эти виды оптимизации более сговорчивыми. Под "ссылочной прозрачностью" я подразумеваю свойство, которое значение выражения не зависит от того, когда он оценивается. Выражения типа 2 + 2 являются ссылочно прозрачными; вы можете выполнить оценку во время компиляции, если хотите, или отложить ее до времени выполнения и получить тот же ответ. Но такое выражение как x+y не может быть перемещен во времени, потому что x и y могут меняться с течением времени.

асинхронность делает его гораздо труднее рассуждать о том, когда будет побочный эффект. Перед асинхронностью, если вы сказали:

M();
N();

и M() был void M() { Q(); R(); } и N() был void N() { S(); T(); } и R и S побочные эффекты продукции, тогда вы знаете что побочный эффект R случается перед побочным эффектом S. Но если у вас есть async void M() { await Q(); R(); } затем внезапно это выходит из окна. У вас нет гарантии, что R() это произойдет до или после S() (если конечно M() ожидается, но, конечно, его Task не нужно ждать, пока после N().)

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

третий пункт против того, что вы тогда должны спросить: "почему асинхронность так особенная?"Если вы собираетесь утверждать, что каждая операция на самом деле должно быть Task<T> затем вы должны быть в состоянии ответить на вопрос "почему не Lazy<T>? или " почему бы и нет Nullable<T>? или " почему бы и нет IEnumerable<T>?"Потому что мы могли это сделать. Почему это не должно быть так, что каждая операция отменяется? Или каждая операция лениво вычисляется и кэшируется для последующего или результатом каждой операции является последовательность значений, а не только одно значение. Тогда вам придется попробуйте оптимизировать те ситуации, когда вы знаете: "о, это никогда не должно быть null, поэтому я могу генерировать лучший код" и так далее. (И на самом деле компилятор C# делает это для поднятой арифметики.)

суть в том, что мне не ясно, что Task<T> на самом деле это особенное, чтобы гарантировать такую большую работу.

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