Я думал, что вы не можете дождаться метода, который не определен как "асинхронный"?
Это своего рода «сокращенный» способ мышления, который может быть полезен на начальном этапе.обучение async, но разваливается, когда вы получаете больше знаний о async / await.Есть два понятия, которые не совсем верны в этом предложении.
Во-первых, код не может await метод.На самом деле происходит то, что метод вызывается точно так же, как любой другой метод.Этот метод возвращает значение - тип awaitable - и именно это возвращаемое значение действительно ожидается.Мы часто говорим о «ожидании метода», но это просто сокращение для «вызова метода и ожидания его возвращаемого значения», что более точно, но слишком неудобно для большинства разговоров.
Во-вторых, async это просто в одну сторону для создания ожидаемого возвращаемого значения (которое затем можно ожидать).Есть также несколько других способов.Например, Task<T>.Factory.FromAsync обычно используется, если у вас есть API, который использует более старый асинхронный шаблон APM , и вы хотите использовать его с await.В этом случае вы обычно пишете методы-оболочки, которые возвращают Task<T> и реализуются с использованием Task<T>.Factory.FromAsync (без async) .Другим распространенным подходом является использование TaskCompletionSource<T>, которое может создать Task<T> вокруг любого логического «будущего события» .
Другими словами, async являетсядетали реализации.Эта концепция дополнительно поддерживается тем фактом, что методы интерфейса могут быть объявлены как возвращающие Task и ожидаемые, но только реализации метода могут быть объявлены с async.