4

私は新しいTask Parallel Libraryを使用していますが、今日はこのケースに行きました:

このコードはコンパイルされません:

    internal Task<Guid?> SavePages(string[] pages)
    {
        return Task.Run(() =>
        {
            if (pages == null || pages.Length == 0)
                return null;

            ....

null の null 許容 Guid を明示的に返さない限り:

    internal Task<Guid?> SavePages(string[] pages)
    {
        return Task.Run(() =>
        {
            if (pages == null || pages.Length == 0)
                return (Guid?)null;

            // Check documents path access

なぜこの振る舞いなのか、私は何か間違ったことをしているのですか? つまり、コードは 2 番目のオプションで動作するようになりますが、わかりません ライブラリを悪用している場合、null は常に null ですよね。

コンパイル エラー:

ブロック内の戻り値の型の一部がデリゲートの戻り値の型に暗黙的に変換できないため、ラムダ式をデリゲート型 'System.Func' に変換できません

http://msdn.microsoft.com/en-us/library/dd460717.aspx

4

2 に答える 2

5

これは、コンパイラがラムダの型を決定する方法に関係しています。プレーンを返す場合null、コンパイラが暗示できる唯一のことは、オブジェクトを返すことです。したがって、パラメーターなしのラムダは と互換性がありTask<object>ます。ただし、関数のシグネチャは を返していることを示しているTask<Guid?>ため、コンパイラがコードから暗示した戻り値の型には互換性がありません。それを にキャストするnullとGuid?、ラムダを にするために不足している手がかりがコンパイラに提供されますTask<Guid?>。

于 2012-07-01T19:22:10.463 に答える
3

これは、C# コンパイラでの型推論の制限です。この問題は、三項演算子に関する問題と無関係ではありません。

int? num = a != null ? a.Value : null;         // Will not compile
int? num = a != null ? a.Value : (int?)null;   // Compiles
int? num = a != null ? (int?)a.Value : null;   // Compiles

特定の状況に対する別の回避策は、ジェネリック型を明示的に指定することです。

return Task.Run<Guid?>(() =>
{
    if (pages == null || pages.Length == 0)
        return null;
于 2012-07-01T21:08:07.003 に答える