Support for ValueTask

Currently FakeItEasy has special support for Task and Task<T>:

• Dummy creation strategy: return a completed Task, or Task<T> whose result is a dummy T
• Special overload for configuring the return value of a method that returns Task<T>, where the user can just pass the task’s value instead of the task itself.

We should consider supporting ValueTask and ValueTask<T> as well. But it might not be as simple as for Task and Task<T>…

• ValueTask<T> is only available in .NET Core (all versions) and .NET Standard 2.1
• ValueTask is only available in .NET Core 2.1+ and .NET Standard 2.1
• BUT there’s a NuGet package supported on .NET Standard 1.0+ that exposes both types

So, if we add support for ValueTask only in a new .NET Standard 2.1 target, projects that target TFMs not compatible with .NET Standard 2.1 and use the package won’t benefit from it. A possible approach would be to offer the Returns overloads for ValueTask in a separate package, and support dummy creation dynamically (like we did for ValueTuple)

Also, ValueTask[<T>] doesn’t work exactly the same as Task[<T>], there are a few subtleties. For instance, you can’t await the same ValueTask[<T>] more than once, which will have to be taken into account for dummy creation (we’ll have to return a new one for each call).

[thomaslevesque]

Would they not also all of a sudden have conflicting ValueTask types?

No, because the netcoreapp3.0/netstandard2.1 TFMs of this package don’t contain the ValueTask type.

But yes, the problem is fairly easy to fix. And we could even avoid the error entirely, by multitargeting the package. The netcoreapp3.0/netstandard2.1 TFMs would contain nothing, since FakeItEasy would already define the extension methods for these TFMs. We could consider including a target that causes a warning (like we did for FakeItEasy.Analyzer) to indicate the package is no longer necessary.

[thomaslevesque]

The same task is returned for every call.

Ah, it looks like my assumption was wrong… in fact we lazily create a new task every time. Just ignore me, we can do exactly the same for ValueTask

Also, synchronously completed ValueTasks (that just contain a value) can be awaited multiple times, apparently. So there’s no problem here after all.