Provide conversion from `ValueTask<T>` to `ValueTask`

[khellang]

When working with ValueTask and ValueTask<T>, I've often encountered scenarios where I don't care about the result of a ValueTask<T>-returning method and just want to return back the task to be awaited further up the stack.

Unfortunately, this isn't possible:

public ValueTask DoSomething()
{
    // Do a bunch of synchronous stuff here...

    return DoSomethingElse(); // CS0029 - Cannot implicitly convert type 'System.Threading.Tasks.ValueTask<int>' to 'System.Threading.Tasks.ValueTask'
}

public ValueTask<int> DoSomethingElse()
{
    // Do a bunch of synchronous stuff here...

    return new ValueTask<int>(42);
}

The workarounds I've found is to either make the calling method async, which introduces a bunch of state machinery:

-public ValueTask DoSomething()
+public async ValueTask DoSomething()
{
    // Do a bunch of synchronous stuff here...

-    return DoSomethingElse();
+    await DoSomethingElse();
}

Or convert the ValueTask<T> to a Task<T> and wrap it in a ValueTask, which allocates a Task<T>:

public ValueTask DoSomething()
{
    // Do a bunch of synchronous stuff here...

-    return DoSomethingElse();
+    return new ValueTask(DoSomethingElse().AsTask());
}

Are there any other workarounds I've missed?

Anyway, I think it would be nice if there was a quick way to convert a ValueTask<T> to ValueTask, without introducing async state machinery or allocate.
Either as an explicit method, or just an implicit conversion that throws away the ValueTask<T>'s _result field:

@@ -118,7 +118,7 @@ namespace System.Threading.Tasks
         }

         [MethodImpl(MethodImplOptions.AggressiveInlining)]
-        private ValueTask(object obj, short token, bool continueOnCapturedContext)
+        internal ValueTask(object obj, short token, bool continueOnCapturedContext)
         {
             _obj = obj;
             _token = token;
@@ -555,6 +555,11 @@ namespace System.Threading.Tasks
         public static bool operator !=(ValueTask<TResult> left, ValueTask<TResult> right) =>
             !left.Equals(right);

+        public static implicit operator ValueTask(ValueTask<TResult> task)
+        {
+            return new ValueTask(task._obj, task._token, task._continueOnCapturedContext);
+        }
+
         /// <summary>
         /// Gets a <see cref="Task{TResult}"/> object to represent this ValueTask.
         /// </summary>

There might be a really good reason why this conversion doesn't exist already, but I don't know the details so I though I would ask; would this be doable?

// @stephentoub

[stephentoub]

There might be a really good reason why this conversion doesn't exist already, but I don't know the details so I though I would ask; would this be doable?

I've considered whether we should add an AsValueTask method. It's doable, and we might want to, but it has some downsides.

The tricky part is for ValueTask<T> backed by IValueTaskSource<T>. There's no guarantee that the implementation also implements IValueTaskSource. We can check if it does, but if it doesn't, we'd need to AsTask(), which would allocate (the alternative would be to allow ValueTask to also be backed by IValueTaskSource<T>, but that gets expensive for the common case... had I to do it over, I may have had IValueTaskSource<T> require IValueTaskSource, but c'est la vie).

So, such a conversion could very well allocate, and as such it shouldn't be implicit.

There's also the concern that it's promoting having then two instances of the same potentially-IValueTaskSource type, and they'd need to be treated like any other copy, i.e. only one should ever be used.

Still, it could be done.

Or convert the ValueTask to a Task and wrap it in a ValueTask, which allocates a Task:

If you wrote:

public static ValueTask AsValueTask<T>(this ValueTask<T> valueTask)
{
    if (valueTask.IsCompletedSuccessfully)
    {
        valueTask.GetResult();
        return default;
    }

    return new ValueTask(valueTask.AsTask());
}

then this won't ever allocate for a ValueTask<T> created from either a T or a Task<T>: in the former case, you'll always be successfully completed, and in the latter, you'll already have a Task<T> so nothing need be allocated. It also won't allocate in the case where the ValueTask<T> was created from an IValueTaskSource<T> that represents an operation which has now completed. It'll only allocate a Task<T> in the case where the ValueTask<T> was created from an IValueTaskSource<T> which either hasn't yet completed or completed unsuccessfully, and in such a case, as outlined earlier, we generally won't be able to do better in the implementation anyway; we could only do better in the case where the backing object implemented both interfaces.

So, doing it yourself will generally be no worse. Doing it in the ValueTask<T> implementation itself would yield only a slight benefit for that specific case where the ValueTask<T> was created from an object that implements both IValueTaskSource<T> and IValueTaskSource and where the operation is still pending.

(Also, it's not even clear we could do better in the "implement both interfaces" case. Some implementations might use the two interfaces to represent different operations, and so assuming they represent the same one could introduce bugs. We'd have to investigate that deeply, and potentially such a built-in implementation could do no better than the above that anyone could write.)

[khellang]

Ah, thanks for a great answer! I guess that extension method would work well enough. It would still be nice if it was part of the framework though.

had I to do it over, I may have had IValueTaskSource<T> require IValueTaskSource, but c'est la vie

There's no way to make this happen? Not even with default interface members? Something like

@@ -62,21 +62,14 @@ namespace System.Threading.Tasks.Sources

     /// <summary>Represents an object that can be wrapped by a <see cref="ValueTask{TResult}"/>.</summary>
     /// <typeparam name="TResult">Specifies the type of data returned from the object.</typeparam>
-    public interface IValueTaskSource<out TResult>
+    public interface IValueTaskSource<out TResult> : IValueTaskSource
     {
-        /// <summary>Gets the status of the current operation.</summary>
-        /// <param name="token">Opaque value that was provided to the <see cref="ValueTask"/>'s constructor.</param>
-        ValueTaskSourceStatus GetStatus(short token);
-
-        /// <summary>Schedules the continuation action for this <see cref="IValueTaskSource{TResult}"/>.</summary>
-        /// <param name="continuation">The continuation to invoke when the operation has completed.</param>
-        /// <param name="state">The state object to pass to <paramref name="continuation"/> when it's invoked.</param>
+        /// <summary>Gets the result of the <see cref="IValueTaskSource"/>.</summary>
         /// <param name="token">Opaque value that was provided to the <see cref="ValueTask"/>'s constructor.</param>
-        /// <param name="flags">The flags describing the behavior of the continuation.</param>
-        void OnCompleted(Action<object> continuation, object state, short token, ValueTaskSourceOnCompletedFlags flags);
+        void IValueTaskSource.GetResult(short token) => GetResult(token);

         /// <summary>Gets the result of the <see cref="IValueTaskSource{TResult}"/>.</summary>
         /// <param name="token">Opaque value that was provided to the <see cref="ValueTask"/>'s constructor.</param>
-        TResult GetResult(short token);
+        new TResult GetResult(short token);
     }
 }

Should I leave this issue open as a request for some kind of conversion in the framework?

[svick]

@khellang

There's no way to make this happen? Not even with default interface members?

If I'm reading Breaking Change Rules (which has been recently updated for DIM) correctly, that's not allowed:

✗ Disallowed

• […]

• Adding a default implementation of an existing interface method (IA.Foo) on an existing interface type (IB)

  User code could already be providing a default interface method implementation for IA.Foo in another interface (IU). If a user type implements both IU and IB, this would result in the "diamond problem" and runtime/compiler would not be able to disambiguate the target of the interface call.
  Note that this rule also applies to providing a default implementation for public interface methods on non-public interfaces that are implemented by unsealed public types.

[stephentoub]

@khellang, I think it's unlikely we'll end up doing anything here. I'm going to close the issue, but please feel free to re-open it or create a new one if you have any good brainstorms on it, etc.

[olivier-spinelli]

For the ones that master the black magic of this, or, like me, would just like to stay on the safe side of the aforementioned magic, I wrote a SO question here about this issue: https://stackoverflow.com/questions/61256813/convert-a-valuetaskt-to-a-non-generic-valuetask

[benaadams]

Could add a 3rd interface

public interface IValueTaskSourceDual<out TResult> : IValueTaskSource<TResult>, IValueTaskSource
{
    void IValueTaskSource.GetResult(short token) 
        => ((IValueTaskSource<TResult>)this).GetResult(token);
}

Then items that implement that (e.g. framework IValueTaskSource's to begin with) could have non-allocating conversion