-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ValueTask factory members #37507
Conversation
Tagging subscribers to this area: @tarekgh |
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/ValueTask.cs
Show resolved
Hide resolved
|
Thanks. Will fix. |
c26a044
to
7c77d64
Compare
7c77d64
to
751d0f3
Compare
@@ -114,6 +111,40 @@ private ValueTask(object? obj, short token, bool continueOnCapturedContext) | |||
_continueOnCapturedContext = continueOnCapturedContext; | |||
} | |||
|
|||
/// <summary>Gets a task that has already completed successfully.</summary> | |||
public static ValueTask CompletedTask => default; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This member feels confusing from an API standpoint. Per https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.valuetask?view=net-5.0:
The following operations should never be performed on a
ValueTask
instance:
- Awaiting the instance multiple times.
Although it's actually legal, it feels like using ValueTask.CompletedTask
leads immediately to violating the above "should never" guideline. If I return this "instance" from my own method, won't my method's callers be awaiting the "same" instance multiple times and violating the rule? (Saying it's a by-value copy and they're actually different instances doesn't resolve the problem, as copying a ValueTask
doesn't provide an exception to the current set of rules.)
If it's argued that this is a special case and can be treated differently, that just makes the ValueTask rules more difficult to comply with, as they can no longer be applied consistently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair question, but that assumes it's returning the same instance each time you invoke the getter. Think of it as a member you're invoking and it's giving you back an already completed task you can use once. It's not special in that way. I can invoke Stream.ReadAsync and use the returned ValueTask once. I can invoke ValueTask.FromException and use the returned ValueTask once. ValueTask.CompletedTask is the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the response; that's a fair interpretation.
I was going to argue that it is then inconsistent with Task.CompletedTask
, which returns the same instance for efficiency, but then I read the docs and saw that "Repeated attempts to retrieve this property value may not always return the same instance.", so TIL.
Fixes #27960
cc: @tarekgh