And since you can use ValueTask<T> as the result of an async method, is the compiler smart enough to generate the appropriate code based on whether such a cached value is used without any async calls being used?

It's more that it's a cheaper alternative to Task, but more limited

Mind elaborating?

It doesn't allocate (as much, at least), but you can't do things like await it twice, or use it with e.g. Task.WhenAll

https://devblogs.microsoft.com/dotnet/understanding-the-whys-whats-and-whens-of-valuetask/ is a pretty good overview, if you haven't read it.

I tend to use it when my method may never need to run asynchronously.

i.e. it never awaits

If I essentially have this

public async Task<string> GetStringAsync() {
  if (cachedValue is not null) return cachedValue;
  
  string value = await DoSomeOtherOperationAsync();
  cachedValue = value;
  return value;
}

Is it worth using ValueTask?

Nice

Why would you await it twice anyway?

Relevant: https://discord.com/channels/143867839282020352/663803973119115264/1008494103857733642

Assuming you mean return Task.FromResult(cachedValue);

But that makes sense

An already completed task?

Well, it'll complete when it completes. That's the point

My own rules are:
I know the async func will almost never complete synchronously => Task
If I know it will return synchronously most of the time => ValueTask

if it's internal function and I already didn't decided with 2 previous point => ValueTask

No. cachedValue is a Task<string> (otherwise none of the other lines would compile)

The point is that if someone calls GetStringAsync (which calls DoSomeOtherOperationAsync) you immediately cache the work-in-progress task. Then if someone else calls GetStringAsync before the task has completed, you give them back the same Task rather than calling DoSomeOtherOperationAsync a second time. If the task has completed, great, awaiting it is a free noop

My view here is that single allocations are staggeringly cheap, and bugs are expensive. I'll always go with Task unless it's a high-perf scenario, in which case I'll have my profiler out and it can tell me if I need to move to ValueTask

🤨 cachedValue is a string not Task<string>

if you are directly awaiting the task

var value = await GetStringAsync();

use a valuetask

if you need to use the task

var task = GetStringAsync();
// await task later
then use a normal task

from my own personal asking around and seeing other people converse on the topic:
use ValueTask if you expect your method to return synchronously a greater-than-negligible amount of times. Use Task otherwise. ValueTask can, to my knowledge, offer a performance/speed gain over Task (if the method performs synchronous work only), but this is only noticible at massive scales where your method is called a LOT. it's not worth fretting over otherwise

A modern API? Not an older EAP/APM API?

difference between task and valuetask is that task allocates a new object on every call but valuetask only allocates a new object if the operation was asynchronous

otherwise the call is allocation free

I'm saying turn it into a Task<string>

Do they return a Task maybe?

https://github.com/dotnet/aspnetcore/blob/c85baf8db0c72ae8e68643029d514b2e737c9fae/src/Components/Server/src/ProtectedBrowserStorage/ProtectedBrowserStorage.cs#L59 so these are mostly passthrough methods where async is ellided for perf. I assume MS knows how to do that properly...tagging the method names with Async can be confusing.

^ This is what I thought when reading your message

I think this is totally fine

how do you mark a thread as done

right click on it => archive

I figured that out and then yall posted again ._.