Здравствуйте, Serginio1, Вы писали:

S> Зачем? Еще раз для асинхронных методов достаточно downloadSomeDataAsync
А почему ты решил, что downloadSomeData — асинхронный метод, притом всегда? Вдруг он что-то просто из памяти достаёт в большинстве случаев?

S> и вызов через await Task.WhenAll
Это значит, что метод содержащий await Task.WhenAll тоже обязан быть async. Зачем??!

S>>>var res = await task; // или в синхронном варианте int res = task.Result;
S>·>Вот зачем этот выбор? Более того, если ты воткнёшь тут "await", это значит сам метод придётся объявить async. И, возможно, это будет интерфейсный метод, тогда все его имплементации тоже придётся переделывать в async (даже если они простые и без всякой многопоточки/io). И все места вызовов этого метода. И где-то выше по стеку придётся ещё воткнуть await.
S> Еще раз. витруальные потоки хороши для асинхронизации синхронного кода. Всё!
Неверно. Для параллельного исполнения, а не асинхронизации. Потоки в принципе для этого и придумывали.

S>·>Зачем это всё?! Почему нельзя просто всегда писать "int res = task.Result"?
S>·>Сабж?
S> Затем, что мы останавливаем и поток для дожидания результата. Ведь он может выполняться значительно дольше чем код кода до task.Result.
S>task.Result это для поддержки старого синхронного кода. Вот где преимущество виртуальных потоков.
Так что же плохого в старом синхронном коде при наличии виртуальных потоков? А хорошее, очевидно, есть. Синхронный код проще.