Make Dapper use the new IValueTask<T> instead of Task?

[kikaragyozov]

I'm not entirely sure if it's being done already. A quick search for ValueTask reveals only this much.

As to why - this read explains it very well, with very important references to github discussions (dotnet/coreclr#26310) for the planned changes coming into .NET 5.

[mgravell]

I wouldn't trust that blog author - that guy's a jerk!

[mgravell]

OK, more seriously; it is a major breaking change; yes, it is something that will be considered - at the same time as implementing IAsyncEnumeable<T> we'll probably make the "other" API something like ValueTask<List<T>> (or possibly something a little more exotic involved leased arrays and explicit lifetimes). But that needs a big chunk of time to look at. Right now I've already got two big refactors going on in two of my other libs, so I'd like to get at least one of those closed down before starting a third concurrent major refactor :)

[kikaragyozov]

Copy that @mgravell , thank you for making Dapper and resolving my last concern ever so smoothly and friendly!

Is it still good from my side though to refactor all my Task methods (ASP.NET Core 3.1) to be ValueTask/ValueTask of T? If you could give me your stance on this, I'd really appreciate it!

EDIT: If I might add, why do you recommend to avoid using PooledAwait in the blog? Is it simply to the risk of awaiting something twice, or perhaps inclining to await the official implementation of Microsoft for this neat feature?

[mgravell]

Well, refactoring anything should always be done with care - and changing the return type of a method or property is inherently a breaking change, so : don't go mad with it; however, I'd generally be OK with switching to ValueTask[<T>] in many places. This is especially valid when many returns may be synchronous, but still has utility otherwise, hence the blog.

As for PooledAwait: mostly, because I'd rather it got replaced by the BCL itself, so I didn't have to support it. If it works for you, and you're happy with it: go wild.

[kikaragyozov]

Thank you so much for the insights! Feel free to close this issue, unless you prefer leaving it as a straw for the future.