{"componentChunkName":"component---src-templates-blog-post-js","path":"/blog/generic-type-inference-in-csharp","result":{"data":{"markdownRemark":{"html":"

Próbowałem ostatnio zrobić takie coś:

\n
interface IWrapper<TItem> {\n    ICollection<TItem> Items {get;set;}\n}\n\nclass MyWrapper : IWrapper<sting>{\n    public ICollection<string> Items{get;set;}\n}\n\nclass Operator {\n    public TWrapper DoSomething<TWrapper, TItem>()\n    where TWrapper : IWrapper<TItem>\n    {\n        // ...\n    }\n}
\n

Następnie chciałem, żeby kompilator sam domyślił się drugiego argumentu generycznego, gdy wołam DoSomething:

\n
operator.DoSomething<Wrapper>();
\n

zamiast

\n
operator.DoSomething<Wrapper, string>();
\n

Niestety, pierwsze opcja wywalała kompilację z komunikatem, że kompilator nie potrafi domyślić się typu tego drugiego argumentu generycznego. No ale - jak to? Skoro określam w where, że TRequest ma implementować interfejs IWrapper<TItem>, a TItem jest drugim argumentem, to chyba wiadomo, że np. dla TRequest = IWapper<int> - TItem = int?

\n

A jednak - nie! Jak zwykle odpowiedź przychodzi ze Stack Overflow - tym razem sam Eric Lippert, który pracował onegdaj przy kompilatorze C# wyjaśnia, że:

\n
\n

A bunch of people have pointed out that C# does not make inferences based on constraints. That is correct, and relevant to the question. Inferences are made by examining arguments and their corresponding formal parameter types and that is the only source of inference information.

\n
\n

:(

","excerpt":"Próbowałem ostatnio zrobić takie coś: Następnie chciałem, żeby kompilator sam domyślił się drugiego argumentu generycznego, gdy wołam : zamiast Niestety…","frontmatter":{"date":"31 October, 2019","path":"/blog/generic-type-inference-in-csharp","title":"Generic type inference in C#"},"fields":{"readingTime":{"text":"1 min read"}}}},"pageContext":{}},"staticQueryHashes":["3649515864","63159454"]}