C# の今後の async/await 機能の設計について、いくつか疑問があります。
Task<T>var result = async GetResultAsync();Async/away は素晴らしい機能ですが、LINQ ほどうまく設計されていないと思います。また、設計チームは現在の設計に危険なほど満足しているように感じます。コミュニティからのフィードバックを考慮していない可能性があります。
どう思いますか？
この種の設計上の決定は、自分でこれを機能させようとするまでほとんど意味がありません。あなたの課題: 非同期コードを書き、いつでも停止できるようにします。制約: Thread.Abort() を使用できず、デッドロックを引き起こすことはありません。
Async/away は素晴らしい機能ですが、LINQ ほどうまく設計されていないと思います。
LINQ の設計プロセスと比較して、設計プロセスのどの側面が不足していると感じますか?
また、デザイン チームは現在のデザインに危険なほど満足しているように感じます。コミュニティからのフィードバックを考慮していない可能性があります。
その印象を与えるものは何ですか？かなり前から、コミュニティからのフィードバックを募集してきました。それは無視されていません。
どう思いますか？
これはディスカッションの質問であり、エンジニアリングの質問ではないと思います。これがこの質問に対する適切なサイトであると確信していますか?
彼らはすでに、この状況に完全に適合するように設計されたTaskとに多くの労力を費やしています。Task<T>これは非常に便利だと思います。なぜなら、Task に何を期待するかを正確に知っているからです (以前にそれを使用したことがあるからです)。他の多くの開発者もそのように感じると思います。私の意見では、それは何か新しいものを導入するよりもはるかに優れています - そして、新しいタイプをよりタスクに適したものにするために何が違うのかさえわかりません. 具体的なアイデアはありますか？
asyncキーワードの目的を見逃していると思います。await(キーワードを使用した場合) 非同期で (部分的に) 実行されるメソッドをマークするために使用されます。コンパイラーは、「魔法を実行する」メソッドを知る必要があります。メソッドを非同期で実行するように「変換」することはありません。そのためには、を使用する必要がありますThreadPool.QueueUserWorkItem。
これについては本当にコメントできません。あなたの意見では、よりエレガントなソリューションは何ですか? Microsoft は、フィードバックを共有していただければ、それを考慮に入れると確信しています。