Skip to content

Commit cb38c08

Browse files
StephenClearyBillWagner
authored andcommitted
Update ValueTask.Result remarks (#2364)
* Update ValueTask.Result remarks * Add note that `Result` is not intended for application code. * Add section for semantics when wrapping `IValueTaskSource<T>`. * PR review and add first paragraph to Remarks for consumers. * Add back in the comment about AggregateException. * Add paragraph of ValueTask restrictions.
1 parent 2e2f073 commit cb38c08

File tree

1 file changed

+15
-5
lines changed

1 file changed

+15
-5
lines changed

xml/System.Threading.Tasks/ValueTask`1.xml

Lines changed: 15 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -45,6 +45,17 @@
4545
<format type="text/markdown"><![CDATA[
4646
4747
## Remarks
48+
A <xref:System.Threading.Tasks.ValueTask%601> instance may either be awaited or converted to a <xref:System.Threading.Tasks.Task%601> using <xref:System.Threading.Tasks.ValueTask%601.AsTask%2A>. A <xref:System.Threading.Tasks.ValueTask%601> instance may only be awaited once, and consumers may not call <xref:System.Threading.Tasks.ValueTask%601.GetAwaiter> until the instance has completed. If these limitations are unacceptable, convert the <xref:System.Threading.Tasks.ValueTask%601> to a <xref:System.Threading.Tasks.Task%601> by calling <xref:System.Threading.Tasks.ValueTask%601.AsTask%2A>.
49+
50+
The following operations should never be performed on a <xref:System.Threading.Tasks.ValueTask%601> instance:
51+
52+
- Awaiting the instance multiple times.
53+
- Calling <xref:System.Threading.Tasks.ValueTask%601.AsTask%2A> multiple times.
54+
- Using `.Result` or `.GetAwaiter().GetResult()` when the operation hasn't yet completed, or using them multiple times.
55+
- Using more than one of these techniques to consume the instance.
56+
57+
If you do any of the above, the results are undefined.
58+
4859
A method may return an instance of this value type when it's likely that the result of its operation will be available synchronously, and when it's expected to be invoked so frequently that the cost of allocating a new <xref:System.Threading.Tasks.Task%601> for each call will be prohibitive.
4960
5061
There are tradeoffs to using a <xref:System.Threading.Tasks.ValueTask%601> instead of a <xref:System.Threading.Tasks.Task%601>. For example, while a <xref:System.Threading.Tasks.ValueTask%601> can help avoid an allocation in the case where the successful result is available synchronously, it also contains two fields, whereas a <xref:System.Threading.Tasks.Task%601> as a reference type is a single field. This means that a method call returns two fields worth of data instead of one, which is more data to copy. It also means, that if a method that returns a <xref:System.Threading.Tasks.ValueTask%601> is awaited within an async method, the state machine for that async method will be larger, because it must store a struct containing two fields instead of a single reference.
@@ -661,11 +672,10 @@ As such, the default choice for any asynchronous method should be to return a <x
661672
<remarks>
662673
<format type="text/markdown"><![CDATA[
663674
## Remarks
664-
If this <xref:System.Threading.Tasks.ValueTask%601> wraps a successful result, this property returns it directly.
675+
This property may only be accessed once, and only after this <xref:System.Threading.Tasks.ValueTask%601> has completed.
665676
666-
If it wraps a <xref:System.Threading.Tasks.Task%601>, the behavior of <xref:System.Threading.Tasks.ValueTask%601.Result%2A> is similar to the behavior of accessing <xref:System.Threading.Tasks.Task%601.Result%2A> on the wrapped task: if the task hasn't completed, accessing the property blocks the calling thread until it completes; if the task has completed successfully, the property returns the result; if the task has faulted or was cancelled, accessing the property throws an exception. The thrown exception is not wrapped in an <xref:System.AggregateException>, which is different from the behavior of <xref:System.Threading.Tasks.Task%601.Result%2A> in the same situation.
667-
668-
]]></format>
677+
If this <xref:System.Threading.Tasks.ValueTask%601> has completed successfully, this property returns the resulting value. If this <xref:System.Threading.Tasks.ValueTask%601> has faulted, this property raises an exception. The thrown exception is not wrapped in an <xref:System.AggregateException>.
678+
]]></format>
669679
</remarks>
670680
</Docs>
671681
</Member>
@@ -702,4 +712,4 @@ As such, the default choice for any asynchronous method should be to return a <x
702712
</Docs>
703713
</Member>
704714
</Members>
705-
</Type>
715+
</Type>

0 commit comments

Comments
 (0)