Closed czimpi closed 2 years ago
Those are very good suggestions. Thanks for that.
The generic version of the ValueTask
(ValueTask<T>
) is not shown in the header (but within the description) on the website, but unfortunately I don't know how to mask it regarding the used build system.
The generic version of the
ValueTask
(ValueTask<T>
) is not shown in the header (but within the description) on the website, but unfortunately I don't know how to mask it regarding the used build system.
Sorry, but I don't get your problem.
The generic version of the ValueTask (ValueTask
) is not shown in the header (but within the description) on the website, but unfortunately I don't know how to mask it regarding the used build system.
Probably related to #209.
I found it somewhat misleading, that the deadlock example in 1835 is referencing ASP.NET, as this scenario was true for classical ASP.NET, but is not applicable for ASP.NET Core as explained by Stephen Cleary in this blog post. The title stating 'single-threaded environment' might also be somewhat confusing: Yes, this rule references special environments with their SynchronizationContext forcing a push-back of the continuation to a special dedicated context (rather than tacking a thread from the thread pool to continue with), but it still might be confusing, as it is possible to create multiple Tasks / Threads within e.g. WPF, so 'single-threaded' might not be the best wording.
I also created a new rule 1840, to explain the fallacies when using
ValueTask
/ValueTask<T>
and advising to either directly await these special types or using.AsTask()
to retrieve aTask
/Task<T>
.