The C# team is considering adding a feature to C# that would allow for arbitrary types to be used as the return type from async methods, with ValueTask<T> being a key motivator. As part of this, they're considering overload resolution in a situation like:
```C#
async Task Method(Func<Task<int>> f);
...
Method(async () =>
{
await Blah();
return 3;
});
```
where a developer previously had a method that accepted a ```Func<Task<int>>```, and then with ```ValueTask<T>``` adds an overload like:
```C#
async Task Method(Func<ValueTask<int>> f);
```
Presumably the ```ValueTask<int>``` overload should be preferred in this case. However, if a developer added another overload:
```C#
async Task Method(Func<IAsyncOperation<int>> f);
```
(assuming IAsyncOperation could be used in a return position), we would not want that one preferred. Thus, if this situation should not be considered ambiguous and require the developer to cast/type at the call site to specify which overload should be used (which might be the right answer), there would need to be some tie-breaking mechanism.
The current favorite mechanism of the rest of the C# design team besides me is using implicit conversions as the way to signal this to the compiler, such that if there's an implicit conversion from ```B``` to ```A``` and overloads that take a ```Func<B>``` and ```Func<A>```, ```Func<B>``` would be preferred. For this to work with ```Task<T>``` and ```ValueTask<T>```, ```ValueTask<T>``` would need an implicit cast to ```Task<T>``` and could not have one in the other direction from ```Task<T>``` to ```ValueTask<T>```.
Today, ```ValueTask<T>``` has an implicit cast from ```Task<T>``` to ```ValueTask<T>```, just as it has an implicit cast from ```T``` to ```ValueTask<T>```. A ```ValueTask<T>``` is just a wrapper for both a ```T``` or a ```ValueTask<T>``` (it has a field for each), and so this is just a quick way of creating that wrapper from either of the two members that make up the discriminated union. In this direction, no information is lost, there are no heap allocations, etc.
In the other direction, implicitly casting a ```ValueTask<T>``` to a ```Task<T>``` may or may not be allocating: if the ```ValueTask<T>``` was created from a ```Task<T>```, then implicitly casting to a ```Task<T>``` would just return the stored task. But if the ```ValueTask<T>``` was created from a value (which is the most common case in scenarios where ```ValueTask<T>``` is used, as it's used in places where you expect synchronous completion and thus to have a value rather than a task), then implicitly casting to a ```Task<T>``` would result in needing to allocate that task as part of the implicit cast, leading to implicit and silent allocations.
I very much dislike the idea of adding such an implicit cast from ```ValueTask<T>``` to ```Task<T>```. However, by having the implicit cast in the opposite direction, we shut the door on being able to add such an implicit cast in the future for such overload resolution purposes. Thus, this commit removes the current implicit casts in order to allow us to decide to add back either (or both) directions in the future.
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.
We use optional third-party analytics cookies to understand how you use GitHub.com so we can build better products.
Learn more.
We use optional third-party analytics cookies to understand how you use GitHub.com so we can build better products.
You can always update your selection by clicking Cookie Preferences at the bottom of the page.
For more information, see our Privacy Statement.
Essential cookies
We use essential cookies to perform essential website functions, e.g. they're used to log you in.
Learn more
Always active
Analytics cookies
We use analytics cookies to understand how you use our websites so we can make them better, e.g. they're used to gather information about the pages you visit and how many clicks you need to accomplish a task.
Learn more
